PoC is a widely used metric in traditional organizations to monitor their projects. Normally such projects can have 40+ people with multiple vendors involved. The project is structured into teams some implement Agile others are not. Sometimes the program management wants to become Agile but they are not sure how to structure their team for meeting compliance and regulation expectations, as well as inherited organization’s practices. Read more…
User stories creation is a useful mechanism for expressing product features collaboratively. However, having sprint goal as list of user stories, based on team velocity, from my view reduces the business value of the sprint. Read more…
The setup is a project involving sub-contractors from different vendors working in highly regulated industry.
The objective is how to make these diverse skills work as self-organized team?
The challenges are:
- Strong command and control culture.
- Non streamlined views on how work needs to be done.
- People work independently with fear to become inter-dependent.
Read more…
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. Read more…
Once I read that a project plan without risk assessment is a kid’s plan. Scrum is great framework design around “continuous risk mitigation” or probably avoidance.
Organizations who run projects in “command-and-control” mentality and making transition to Scrum are challenged and normally resort to ScrumBut implementation. ScrumBut is a low-fidelity flavor of Scrum which for me can be worst than command-and-control as it deprives the organization from doing full-fledged risk management.
Risk management is a proactive critical component in either Agile or traditional world. Agile project management de-emphasizes formal risk management. Because if Agile is adequately implemented then all benefits of doing risk management are attained. From my view, good Agile implementation can provide results which far exceed the implementation of formal risk management.
ScrumBut is where the organization wants to move to Agile but held back by its legacy of bureaucracy and inefficiencies. ScrumBut is where leadership is in the test and instead we have mediocre people who try to survive by implanting waste. That waste creates environment where morale is low and is characterized by excessive motion but with little accomplishment.
For ScrumBut I highly recommend going back to the basis of pro-active project management which can be implemented through effective risk management at various levels including:
- strategic
- technical
- teams
- sub-contractors, and
- others
Ignoring formal risk management in ScrumBut creates domino effect of spiral project failures, because of losing the pro-activity which is the back-bone of Scrum.
I had a meeting with a new Scrum team which already had business/analyst, before transitioning to Scrum, who was designated as the product-owner (PO). He was one of the most participating attendees in my Scrum class which I deliver to more than 150 employees. Read more…
I tend to instill the Lean mind-set into the act or may be art of Agile requirements management. User story workshop which we conduct shortly after developing the product vision can be very useful, because: Read more…
In implementing Scrum, we create a team Improvement Backlog. The items in this iBacklog can be:
1. Organizational impediment: This is an organizational change, for example, to create a new role called Product Owner as the single point of contact to the team.
2. Infra-structural improvement: The adequacy of Definition of Done is limited by the infra-structural for the development. For example, ability to make hourly build and integration of code lines from various teams.
3. Team practice to be implemented: Team practices include self-organization, collaboration and empiricism. This is in addition to engineering practices.
4. Scrum ceremonies
5. Other teams coordination
To quickly boot-strap Scrum implementation in a team, I found that prioritizing the iBacklog and starting as soon as we can increase the chances of success in implementation. For example, there may be 1-2 organizational changes to be resolved, then we agree on Definition of Done, then implement Scrum ceremonies directly.
If we succeeded in implementing the ceremonies, Scrum will help in surfacing more improvement opportunities during retrospectives and other Scrum control points. Scrum Master or coach should maintain this iBacklog with the same rigor the Product Owner maintains the product backlog.
What I learned from Theory of Constraints that the overall system performance is determined by the slowest component in the value chain. What I learned from lean (esp Toyota Production System) is that we implement fastest way to respond to client demand and removing waste which elongates the Lead Time. What I learned from Agile is that software teams are self-organized in order to commit on delivering client valued software incrementally and often. Read more…
My understanding that the term project in software development is at best confusing. The engineering team consists of all skills needed to produce increment of the software product. The term release is more indicative than “project” for the kind of work done by the engineering team. The release establishes the following:
- Release defined features.
- Sprint-wise stories forming the slicing of requirements in order to create the release features incrementally and often.
- Release tracking charts.
- Release creates a shippable client product while interim sprints are increments which are potentially shippable
- By end of the release we create plan for the next release.
- The release plan is the way to bring the product road-map to reality.
- The business value delivered to the client is measured by the overall business value of the features of the release features.
- The release plan has associated budget and estimated business value.
- Risk assessment was done at feature level and in totality constitute overall release risk.
- There is NO project manager. The LEGO guy at the right doesn’t lead this funny LEGO wagon. Instead there is facilitator who has no authority but capable to help the team to adopt the Agile principles.
The business people should understand that the team works according to its release plan and not to their project plan. This understanding should shift the organization from project paradigm to team paradigm. Sales people should create commitments based on the backlog and release plans per team.
