Category: Agile

Agile Lean

Decoding Agility: The Critical Role of Cycle Time in Efficient Workflows

It’s widely recognized that just strict adherence to agile methodologies such as Sprint huddles, Backlog grooming, Sprint planning, and Sprint retrospectives doesn’t automatically ensure agility. The first step involves conducting a simple statistical analysis of your Cycle Time data. Once obtained, basic statistical calculations can help establish a baseline.


The agile mindset – what does it mean?

“Developing a product takes time. The only way to do it is to experiment. Build a prototype or a sample and show it around. Let people kick the tires, touch it, feel it. Let them get a taste of the product. Get their feedback and incorporate it into the next prototype you build. Do it fast.” Sounds like something a Lean Startup practitioner would advocate, doesn’t it? But, you see, I got this from someone who worked in manufacturing all his life and never heard the term “Lean Startup”. He went on to say, “You’ve got to listen to the people doing the work. They do this day in and day out. If you want improvement ideas, listen to them. Solve their pain points and see productivity increase.” Sounds like agile thinking, right? With the right attitude, one can adapt the learnings across industries.


Transforming from waterfall to agile

Introducing agility into traditional systems development processes is never easy. Firstly, you have got to want to change. Secondly, you need to have a vision of what to change to. Finally, you need the tenacity to forge ahead in the face of stiff resistance. It is usually the third that is the most difficult journey to undertake. The hardest part of the journey is during the transition wherein you show how to bring agility into executing projects. You are walking the fine line between traditional methodology and incrementally introducing change.


Scope creep? Bring it on

Ask any project manager the reasons why projects fail and one of the reasons cited will definitely be scope creep. But is scope creep really that bad? I don’t think so. Your view of the scope creep will depend on how you manage projects. You can manage projects as a contract or you can collaborate.

I think there will be a scope creep when there is a contract between the solution provider and the consumer. For example, it is notorious in the construction industry. In fact, some contractors want the consumer to change the scope in the middle of the project. That’s their way of making money; it is not like you are going to change contractors in the middle of the project. But if both parties collaborate, then scope creep as a reason for project failure just melts away.

Back To Top