SCRUM Control Process

Lots of times, when managers look at Agile processes and Systems, what strikes is the difference from command and control structure.

A typical project has plans, documents, sign offs, change requests, invoicing, all that are done at managerial level and then passed onto teams for coordination and implementation. The traditional model works with defined facades and interfaces with the good intent of maximizing time and to fix responsibilities and accountabilities on individuals.

However, current businesses always do good with best ideas and bringing them to fore, where ever they reside. Agile  allows us to create a working, practical system where the accountability is divided equally among all team members for success of projects. Thus, with equanimous participation in
1. User stories creation and estimations,
2. Prioritizing backlogs,
3. Determining sprints and schedules,
4. Identifying dependencies,
5. Tracking effort charts,
6. Continous integration,
7. Testing of incremental builds,
8. Sharing status, impediments and ideas in kick offs, stand up meetings, retrospectives,

all team members develop ownership of their respective roles. This facilitates an accomodative styles to enable and empower their teams to finish their work without lag times.

An important lesson to be learned for leadership and sponsors is to identify a good functional and co-opting members on SCRUM projects over using SCRUM on a dysfunctional team. Often the by-product is that you get a better team co-ordination and could convert a dysfunctional team by introducing SCRUM, but that is a risk and need not be the main objective.

An agile structure is not a deflated control system but a leveraging system by ensuring distributed controls across individuals. The onus is on successful delivery as a master than a manager. 

Sprints as a Number or a Named Instance ?

Do you call your sprints as sprint 1, 2, ... or do you assign names to your sprint ?

This post shares my experiences and thoughts based on the various views that I have encountered with my teams.

1. Numbered Sprints are a great motivator. When you start saying Sprint 5, 9, 15, it really gives you the pleasure to know that earlier sprints had a successful closure. This itself motivates the team to conclude sprints with an actionable product and refer to the finished product at each sprint as proof of their capabilities.

Named Sprints are referencible and give a direction during the current sprint. The practice of code names for products under production comes from product manufacturing industry. The code names for Sprints orients the team and when talking instead of an arbitrary number. The name tends to bring about cohesiveness in teams, particularly when you are establishing sprint teams.

2. Numbered sprints become quite flexible as there are no boundaries established in the minds of stakeholders. Hence there are chances to add/modify priorities and user stories in sprints although SCRUM disallows this practice. It is difficult when stakeholders are new to SCRUM and wish to have many features in a single Sprint.

Named Sprints has potential to live up to the name and can ward off intrusions. Once the name of Sprint is decided with stakeholders, it kind of acts as a barrier for inserting more features that do not live upto the principle and Sprint Vision in the overall product vision.

3. Numbered Sprints are difficult to run in parellel. Again since numbers hold a sequence, stating that Sprints 3,4,5 are running with parellel teams, becomes cumbersome to manage and remembering the priorities of each.

Named sprints are good to align parellel sprints. I normally have a sprint called "libs and interfaces" that run in parellel to initial few sprints. It then makes it easy for me to have other sprint leads ask/discuss the features that can be a global library rather than reinventing the wheel within individual sprint teams. Thus  for effective architecture and design, named sprints become ideal for user story transfers.

4. Numbered sprints do not lend themselves to reporting well. For example, when comparing velocities and individual sprint team performances with stakeholders regarding complexities and user story completions vs iterations in sprints, it is difficult to visualize the working of the team.

In Named sprints, it is automatic to gauge the performance against the metric numbers as the names of the sprint and the numbers seemingly make a sense. I realized this because I use EVM for reporting. I initially used to report performance week wise, then tried to report it as Sprint numbers, but when speaking of numbers with respect to a phase/name of sprint, it is good to debate and understand the variances.

This is a matter of cultural taste and the SCRUM implementation maturity within your organization. To date, either of the projects (numbered sprints or named sprints) have been successful for me in aligning business goals to project results. So far, I do not have emperical evidence to prove if a numbering or naming sprints is good. May be few more experiments might yield some direction and shape up my personal preferences.

Has this topic been a concern in your work sphere? Is there a standard SCRUM terminology that needs to be adhered ? Are there any related experiences that you can share ? Looking forward for best practice evolution with collective intelligence.

SCRUM Survival - Need for SCRUM Evangelists

If you are like me who believe SCRUM not only will solve the current project problems but also give a good and sound structure for building a high performance team and you are the first proponents in your team/organization, Read On....

SCRUM way of working requires a "cultural" change. It, hence requires mindset change, belief in common sense that at times are counter intuitive, letting go of control and living always in middle of collaborating and democratizing decision making and importantly needs backing of the entire organization structure to support it.

SCRUM is not a start and stop application. It requires calibration till the "cultural adaptation" meets Agile goals as per the SCRUM framework and enables you to achieve results quickly, with all round satisfaction and happiness.

How do you initiate SCRUM in your organization ? How well and how much do you require to sustain it ? When do you have to push SCRUM mainstream ? How do you address skeptics, fence sitters and passive supporters ? Where does the critical mass lie ? When can a SCRUM implementation move beyond "you" to a culture that you have enabled multiple evangelists?

The series of blog posts seeks to address these burning desires. Some of the points in these posts will show a bias towards my personal thoughts and tribulations in my trial runs by fire with one and only belief that

"SCRUM is a GREAT philosophy to execute WELL-RUN projects"

Part 1: Need for a SCRUM Evangelist:
SCRUM literature does not speak about it. The belief is that roles in SCRUM would be their own evangelists. However in practice, it is important to seek one. Here is a first pitch job description of a SCRUM Evangelist.

Adapt:
1. Must believe and understand the Agile Manifesto. Important to repeat it atleast once a day. Speak about it in meetings when resolving decisions and issues.
2. Must be a signatory to the "declaration of inter-dependence"
3. First should be able to learn to adapt and then to introduce rules. Have seen SCRUM Masters come in and say, we do not need Project Managers. First death knell for any initiative is to remotely associate and introduce insecurity in workplace in taking an initiative.

Amend:
4. Can demonstrate ability to resist temptations to

4.1 Move back to old ways of working.
4.2 Being dogmatic about SCRUM rules and thereby be inflexible

5. Fearless for loss of job, failure and share success. SCRUM Evangelist must be driven by motive and attempts made with every learning to make SCRUM successful for future benefits.
6. Should be a prolific writer who can identify success stories and propogate them with tying in relationships to SCRUM methodologies through presentations and articles.
7. Make sure to customize SCRUM over and above SCRUM mandated policies. It is required. SCRUM may not answer say the budgetary spends or for that matter, the remaining time to completion vs the time a story is dormant in a queue. (Burndown charts have their own limitation).

Associate:
8. Should be a person who does not rely on tools and does manual work, if necessary multiple times. Start with available tools (Excel, Paper, Charts, Post Its, etc). Then introduce tools that make more sense to the culture.
9. Must be a person who can think "culture" and not "process"
10. Conduct Retrospectives and document and share learnings across teams.
11. Constantly speak the SCRUM lingo for any reference to make people imbibe the SCRUM way of working.
12. Should be able to build a name-product association with SCRUM. Think Agile, SCRUM, Think "You" the evangelist.

How else have you evangelised and introduced SCRUM in your organization ?

Harmony between Multiple Management Theories

One of the promises and a great point that theories of
1. JIT
2. Critical Chain
3. Agile Practices
4. Earned Value Management
5. Systems Thinking
propose is to streamline operations and management across every key business functions. And the target of reducing waste is multifold:.

1. Keep near to zero inventories
2. Identify the bottleneck (Constraint) and work to eliminate the constraint. Never let Inertia be the constraint
3. Make Velocity the primary driver on projects
4. Plan closer to realities and meet forecast due dates and costs every time
5. Ensure to look at whole than to address it in parts (more appropriately think long term than to spoil it for short term gains)

What each of the theories explain is in harmony with other theories. It is the context and culture that defines the importance of a theory over other that determines the extent of practice within an organization and industry. Manufacturing and automotive industries is
where JIT had its origins. Book "Goal" where ToC parable was made known
to everyone is set in a plant. IT and software industries do not need warehouse inventories as they rely on human capital. Hence agile practices are more common. In RnD organizations, science and infrastructure industries that need heavy investments and need long term management for results and control on cost escalations, EVM is more appealing. 
In my experience at team, product, project and service management, I realized that bringing in the understanding from each of these theories and crafting your operations model is a great way to deliver exceptional customer satisfaction, team achievements and a sustainable long term sustenance of business, teams and clients than a short get-together for climbing up professional ladder.