Chess -

Archivos de Categoría: English

Theory of Constraints (TOC)

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.

When everything is a priority, nothing is a priority

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”.

How does Agile help you to deliver?

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).

Deadline Driven Development

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.

Too small to fail

Kaizen, or continuous improvement, is a well-known term in business or industrial organization. It’s now spreading widely in every sector of the economy, but it also applies in social life or medicine. This philosophy arose in Japan. Their industry had  productivity and quality problems after the end of World War II. They looked for solutions, and brought experts such as  Deming. Yes, the same Deming of ITIL and the “plan-do-check-act” Deming cycle. His mission: training hundreds of professionals and engineers in quality and improvement systems. These methods had already been applied in the USA. But Japan developed them and improved them. They refined them to such an extent that years later they could return them to the Americans themselves as new work philosophies.
The principle behind Kaizen is to carry out small continuous improvements. The results of those changes are analysed and the fine-tuning resumes. In that way  the productivity or quality of the task being performed can be improved. Making small changes little by little is far more effective than trying to tackle everything in one go. This way you avoid the fear of big change—and the procrastination that normally goes with it —when faced with the idea of starting a transformation. These small adjustments, done continuously, end up becoming a habit and generating permanent results.
The idea is to make changes so easy that it would be hard to fail in their implementation. First we created the habit of changing. Then we add new changes or nudge the milestone of a change a bit further, so we can improve incrementally. It’s important to apply adjustments one by one. The idea is to avoid the complexity of choosing what to apply and when. That way we will be able to analyse the result of each of these minor improvements. If we apply several at the same time, we won’t know which one has worked and which hasn’t. Or whether the effect of one has cancelled out another.
In your project you can decide to deploy every SCRUM, TDD, unit testing, continuous integration, and so on and so forth all at once. But probably the only thing you’ll manage to do will be to drive your team crazy. Yes, all those practices are good for your project, but, are the most basic ones working? Do you have good version control? Are you delivering software every two weeks? It’s better to start by the simplest ones or the ones that you consider most effective to improve your situation. Then you will be able to add the others.
Even far away from the field of software, there are companies that use Kaizen and Lean techniques in production. Take, for example, SPB, manufacturers of household brands like Bosque Verde in Spain. Their industrial manager declares:
“SPB has improved its productivity by 15% without investing in new machinery or carrying out staff cuts. The systems we have applied have enabled our company to reduce our expense accounts from 15 to 25%. We have improved our raw-materials management by 45%. And we have reduced the stock period of our product to eleven days.”
SPB had foreseen that to improve, they would need great investments and opening new factories in northern Spain. But instead they have focused on improving their productivity plan.
We can apply such changes to improve our health or personal life too. If we have always wanted to write a book or a blog, we can set out to write 1,000 words a day. But most of us will probably abandon that idea in only a few days. However, if we set out to write just 50, the change will be so easy that it will be hard to fail. First, establish the habit of sitting and writing for 15 minutes a day. Then we can take the challenge further and make it bigger, little by little.
In my case, I have also applied similar techniques, but I’ve hardly noticed. When I published my book it hardly sold at all. For weeks and weeks it had just the few sales I considered F&F (Family & Friends). But I didn’t just park it there and forget about it. I changed it to a different Amazon category. Then I changed the cover. After that, I included some new chapters. Later, I improved the description until I found one that seemed optimal. Some of these changes made my sales increase up to 50% in a week. If I had just left it there, the book would never have reached decent positions in its categories. I would have concluded that the content wasn’t interesting. Or that it just could not sell well without a professional publishing house to support it.
You can find texts like this and many other about how to manage agile projects in my book Agile 101: Practical Project Management (available on Amazon).
Book on Scrum: Agile 101, Practical Project Management
Agile 101 – Practical Project Management

Translation by Begoña Martínez. You can also find her on her LinkedIn profile. Proofreading by David Nesbitt.

Esta web utiliza cookies propias y de terceros para su correcto funcionamiento y para fines analíticos. Contiene enlaces a sitios web de terceros con políticas de privacidad ajenas que podrás aceptar o no cuando accedas a ellos. Al hacer clic en el botón Aceptar, acepta el uso de estas tecnologías y el procesamiento de tus datos para estos propósitos. Más información