Posted by Yannick Martel on June 12, 2009
Without a good product owner, a project can go that bad!
I expressed on a recent post that the activities done upstream from software development where amongst the most difficult ones in producing a quality software product. Specifically, I was thinking about the role of the product owner.
A software developer has a very creative job, implementing requested features, within the boundaries of time and the constraints of language, framework, existing software and knowledge. Still, the job is pretty clear, even if difficult at times. Then tests, automated or not are there to help declare a job is done.
The role of the product owner in an Agile project on the other hand, is to will something and communicate his willingness. He is to produce a view of the software which would be the most useful for the company or organization, define a trajectory, negotiate with peers, feed this view iteration after iteration to the development team and interact on a daily basis to adjust. It is a bit like the job of a captain guiding his ship through a difficult passage, but without the ability to be happy about your job even if you reach a “correct” destination.
As a ship captain, a good product owner must listen, and then decide – I repeat as it is very important: listen and then decide. We concentrate here two major risks, on which the whole project might flounder: listening without deciding or deciding without listening. This is willing with being helped. Alas, in many corporations willing is not encouraged amongst managers, as it goes with taking risks, and accepting help is seen as weakness.
Is that an obstacle to truly benefiting from Agile methodologies? Yes, but indeed no project can go right without somebody assuming this charge, whatever the method – as for many things Agile only help making it more apparent.
Posted in Agile, IT, Methodologies | Leave a Comment »
Posted by Yannick Martel on June 12, 2009
Are you paying attention?
From Lean Management and The Goal, you know where to look for when you wish to improve a complex process: you need to search for bottlenecks in the process flow, and first of all the major bottleneck. Find it and then concentrate all your actions on improving it. Then the process will get better (produce more and/or faster), but you will find have another bottleneck, another limiting factor. Just find it and work on it, and so on.
In IT, Agile has been proposed as a solution to the difficulties in the software product development process. As Agile concentrates on software design and development, it can really help only if difficulties were indeed in design and development. That’s probably partly true as we effectively see improvements when Agile practices are really applied in development projects.
But then from Lean Management, we know we should look for the next bottleneck in the process. Where to look for it? We get an answer by looking at a typical Agile project: somewhere between three and eight weeks after the beginning, the pressure is no more on the development team but on the product owners. And thus we have found our next (and maybe really first and most important – why not?) bottleneck: the team in charge of knowing what to ask.
To me, it is particularly important to effectively address this bottleneck, first because the bottleneck is stronger: knowing what to code is at least as important as knowing how to code it – and generally coding correctly is easier that knowing what to code. Once the development team is ready and eager to produce value, all concentrated on it, it can gell pretty fast and request to be guided, request to know what to produce – pressure has moved.
But there is another, more subtle, reason: softtware development is more related to product design and development than manufacturing (more related to designing a new model of Prius than manufacturing it). It is a profoundly creative activitiy, requiring communication, trust and confidence. If a strong bottleneck is left in the process and it is not addressed, then you risk mining the efforts which have been done elsewhere and loosing everything you’ve earned. More concretely: if your product definition process is visibly the bottleneck and you don’t address it, the demoralizing effect will destroy whatever gains you’ve done by implementing Agile in your development team and you’ll quickly loose the discipline to go on with Agile practices and continuous improvements – maybe creating a secondary bottleneck again.
Posted in Agile, IT, Methodologies | Tagged: Agile, IT, Methodologies, Product definition, Product owner | 1 Comment »