Archivos de Categoría: English

You have been working in chronograms, Gantt diagrams, risks and resource management, more graphics specifying who reports to whom, dreamed plans, and the name of the people who should be blamed in case of not meeting a deadline. You are probably thinking everything is under control, but nobody reads those documents, skimming them at best. 

When you see paperwork like that one, you might be thinking “What a great project manager I am. Every single detail has been captured”, but it might be only an Illusion of Control. What are you doing to help the team to be more productive? How do you plan to overcome Parkinson or Hofstadter’s laws? Other than getting everyone nervous when a deadline is getting closer, have you helped them to remove obstacles? Are you sure the team is delivering value? Ticking a checkbox for every completed task is not getting you any closer to the objectives if the outcome is faulty or doesn’t provide any utility.

It’s based on the search of bottlenecks and critical paths in your operations, so you can improve the process as a whole as any improvement in that point will enhance the total outcome. The idea comes from factory lines where a machine or an activity is delaying the whole line and preventing you from manufacturing more tomato soap cans. 

Your team probably (I hope) follows a sequence of actions: First user story is refined, then developed, tested, reviewed by colleagues, after that a pull request is triggered, software is merged, then tested in an integration environment, and finally reviewed and approved by Product Owner. What is constraining you from delivering more value at the end each iteration? Maybe your refinement session is not long or frequent enough to get all the stories refined, or perhaps Tech Lead is too busy for the huge amount of pull requests she is receiving, and they start to pile up in the repository tool. Do you need another pull request approver? 

Analyze the series of steps your team follows. Try to tweak your proceedings a little bit every time. You’ll make significant progress in your cycle time.

I remember when I read the book “Prioritizing the Product Backlog” by Roman Pichler. He wrote: “I’ll never forget the day when I suggested to the product manager of a new health-care product to prioritize the use case pile in front of her. She looked at me, her eyes widening, and replied, ‘I can’t. They are all high-priority’”.

Quoting to Karen Martin: “When everything is a priority, nothing is a priority”. I have faced this issue too. I tried to solve it by telling the manager that the team couldn’t be working on five tasks at the same time and asked her what she wanted to obtain first. She didn’t hesitate a second and pointed to one of the user stories. “No doubt,” she said, “this one, definitively”.

Have you ever wondered why Agile is so widely adopted? How does it help companies to deliver sooner and better? Here are some tips:

• Releasing frequently improves customer satisfaction and allows the client to decide how the product is evolving.
• Sprints are small milestones. They help you to overcome the Parkinson laws and avoid feared deadlines at the end of the project, when little can be done if something went wrong.
• The Kanban board, the backlog and the sprint backlog make visible the pending work and how we progress (have a look at the Checklist Effect by Atul Gawande).

I have recently read the article «Deadline Driven Development» from Simón Muñoz. Quite a captivating one.
As in TDD, we create tests before developing the solution, he suggests setting a deadline before estimating, and then doing only what can be done until that deadline.
There are multiple perks to that approach: product managers avoid scope creep, and adding unnecessary features to the product being built. Other than that, developers will reduce the overengineering or creating too complex solutions, far beyond what is needed.
We will be reducing waste by building applications or services with just the two or three most important uses cases . Then, we can release our service, and see what was useful, what our clients require now, when they can use the product. From that point we can make more informed decisions on investing more, and better (or to cancel the product).

See the link to the original blog post (in Spanish): Deadline Driven Development by Simón Muñoz.