The more I watch movies or read stories, the more I get impressed by the author’s perspectives and rich imagination. Such stories make me wonder about how strange life is. When I face my own life events, I can’t apply what I have learned from those stories. They can enrich my experience but I should find my own way out. Continue reading
I work with Agile cross-functional team who don’t meet Scrum prerequisites but still want to move toward Agile. I don’t have the authority or can sell the tenet to management to change their team set-up.
People in the team came from different departments and there is lack of understanding of queues and hand-offs. We are not waterfall, rather we are Lean concurrent parallel work in analysis, design, coding, testing and system test.
Five years ago I prepared report for a Lean transformation for a certain client department. The PCE was less than 1%! PCE is defined as the ratio between the time we actually spent working on a feature to the Lead Time. PCE is an average metric.
The purpose of this blog is to explore if there were only one metric to choose, should it be the PCE and why. Continue reading
Process improvement has been doomed to be a waste function by many organizations. From my background, many who work in process improvement are treated as compliance workers instead of being contributors to the bottom-line. For me process improvement is the business. Every day we take decisions to get certain benefits. Continue reading
For large organizations, projects are often characterized of being:
- Involve people from various departments with separate reporting structure.
- Involve contractors from multiple vendors.
- Introduce technology which is unfamiliar to the employees.
- General disagreement or even lack of appreciation of the project approach.
- Multiple chiefs and puzzled doers.
- Software development is sub-component of the project. Continue reading
I suggest starting with implementing the Agile ceremonies (e.g. release planning, sprint planning…..), because:
– These ceremonies require minimum training to introduce process discipline
– These ceremonies facilitate learning about real issues and improvement opportunities
– Can quickly produce results of having shippable product every iteration
– Can dramatically improve collaboration and alignment of the team with the organization and its customers
Once the Agile management practices are in place we will have the forum to develop continuous improvement including the introduction of technical practices (e.g. code review and continuous integration). Introduction of these practices will be based on causes, ROI and group agreements. Starting with engineering practices, from my background, would not be sustained if it’s not supported by disciplined process. The disciplined process improves developers morale and motivation. Motivated developers are prerequisites for developing quality code, yet alone the engineering practices.
A disciplined process produces metrics and provides visibility to management. This can allow the Agile team to sell the improvement and the acquisition of new tools or receiving technical training.
I have worked as Agile facilitator in a project which before I joined had had unit-test-automation part of the development cycle. In reality there were many developer bugs. The process was not helping developers to obtain the benefits of introducing engineering practices. The ROI to the organization was low. As we introduced visualization and Agile ceremonies engaging all related people we all found the technical issues which will help in reducing defects. The level of understanding and buy-in from various team members and other related groups became higher.
It depends on the implementation, usually I suggest to introduce technical improvement 1-2 months after Agile ceremonies are introduced.
Ben, an engineer in our development team reported two issues from production and he didn’t like to report them as bugs. A bug is visualized as red card on the visual board and is visual to the whole organization. Continue reading