Agile Project Management and Communities of Practice

Reading literature on communities of practice, I was able to synthesize my earlier reading of book Presence and find its relevance in my application with Agile teams that I currently manage. The concept in the book and in communities of practice, reminded me of a key component of success - Learning is fun only when you are in presence of a peer group that is determined to succeed and evolve, as much you wish to grow yourselves by doing it together.

Community over Self is how people claim that goodness prevails.Invoking the altruism in the statement sets a lofty goal that many want to miss in a goal-oriented,capitalist world. Community with self is a better promotion and hall mark for all great accomplishments. Coz in every accomplishment,  social good elevates the self and hence a greater good is accomplished. Take example of project teams. While every one accomplishments are bound to be exemplary, it is the collective deliveries that make the success sound sweet.

In Traditional empirical model of management, there are lesser known contributors and few go beyond call of duty. This is because of control-command structure that resides with manager planning and assigning tasks. Ownerships aren't collective. Finding a piece of work and judging its priority and executing it is a self-organizing team's strength. This is what communities of practice do. Since there is ownership in center of the team's existence and the getting together is voluntary, working together differs from a transient loosely assembled Just-In-Time project teams. Thus contributions come from every one and each of them enhance it to levels set by their peers in an automated fashion.

This is aptly captured in Declaration of Inter-dependence manifesto that is foundation of Agile Project Management.

via ScribeFire

5 major mistakes I did in my SCRUM project

1. Did not contain the length of Backlog items:
 I allowed it to expand. While backlog can be stretched and it can theoretically expand to infinity, it is a real bad idea.
This means that project planning did not factor in the schedules or was deferred to later stages of the project to accomodate moving targets based on users requests.

Although a subset alone needs to be taken in Sprint, the inter-dependencies between feature sets and integration challenges with mounting scope always carry the mine to derail the project. Easier to understand, but it took me a beating to realize the importance.

2. Pile up Ahead in Queue: While fresh development was executed in Sprints well, it all piled up ahead in queue in review-fixes stage. This Sprint is where all problems originated.

In my project, there are 4 dependent stages where reviews are done by clients and vendors. While we executed a batch and delivered it to the review stage, in interest of time, we moved into a fresh Sprint, than waiting for review cycles to complete. Thus a Sprint was defined till a review stage. The issues in earlier sprints started coming in during reviews and some had a global impact. When we took the fixes in a separate sprint, the length of that Sprint backlog became high (due to a combination of multiple sprints) that it slowed down the project progress considerably.

Thus final closure got delayed till all dependencies were cleared across all the deliveries in earlier Sprints.

3. Bring in more people in middle of Sprint: 2 new resources were brought in the middle of sprint and they were expected to test the features based on understood logic and functionalities. With no background, they let issues pass through to the deliveries. These issues then extended the Sprint thereby affecting start of other Sprints.

In the end, the timelines of the project had to be shifted before final deliveries started to happen.

4.  Did not enforce sign offs and Prioritization at start of Sprint: Well, this was done at an informal level. But closure of a Sprint through Sprint reviews and Retrospectives, didn't happen formally. This led to a major escalation, that was then brought under control.

5. Clients and Vendors were not fully in SCRUM Wagon: While we pulled in SCRUM practices and principles, the roles of clients and vendors and their roles within the SCRUM project weren't fully articulated. We had their buy-in for sure. While Agile and SCRUM presented a good development picture and initially worked well for shorter deliveries and near to final shippable products till the control was with us, the complete cycle was not implemented within the SCRUM vocabulary (like Sprint Planning, Sprint Reviews, Sprint Retrospectives, etc) involving all stakeholders from clients and vendors alike. There wasn't an issue with this, but may be if this would been practiced, the schedules, efforts and planning would have become an easier affair.

Did I screw up my SCRUM project. No. It is just that these didn't work well or that they weren't done as prescribed.
May be call it a "Theories vs Practice", "Knowledge vs Experience" or "Go by Book vs Customize for the needs" paradox in which these issues got uncovered.

A lot wiser and a lot less inhibition in going with my next SCRUM implementation .

 

via ScribeFire