Building Products for the World We Live In

A friend of mine, who is a PMO by profession, suffers from color blindness and struggles to distinguish between red and green color. And as a PMO, she lives in a world that’s painted Red-Amber-Green. She shared some funny anecdotes related to her impairment and the situations she has found herself in and we all laughed about it.

But it got me thinking – are we building products that are accessible to all? Continuing that line of thought, are we building products that are inclusive? How about products which are environmentally sensitive?

As product managers, product owners and others who have influence over a product’s vision, roadmap and features, we think of various aspects starting with Functionality, Quality and Testability. The non-functional requirements are a much larger group of -ities and -ilities. If we are able to give due consideration to Performance, Security, Scalability, Maintainability, Operability, Portability, Availability etc., then we are probably churning out some pretty awesome product features.

Let’s take this a step further to include Accessibility, Inclusivity, Internationalization and Sustainability.

Why? Because of the world that we live in. There are over 1 billion people in the world who are differently-abled, 50% of the world’s population is female, we have a growing ageing population, technology/internet penetration is pretty high all over the world. And lastly, our home planet is suffering the consequences of climate change every day. If we can make more sensitive products, then why not?

“Make the world a better place” – how’s that for a mission statement to get the workforce motivated and rearing to go!

Accessibility –

The ease with which everyone is able to access and use our products and features is accessibility. Everyone includes people who are differently-abled, have age-related impairments, have technology constraints.

Some of the things that we can take care of to promote accessibility of our products (which any good UX designer will be able to tell us) – larger fonts and icons, better contrast, having Assisted modes (for visual, audio impairment) etc.

Some of the things which make our products less accessible – no audio options for content, using colors like Red/Green only to convey information, no text options for videos, using very small font, very low contrast, relying on highly developed fine motor skills and others.

 

Inclusivity –

When people of different genders, races, ages, beliefs, orientations etc. feel welcome in our products and platforms and there is no “othering” of these groups, we have built inclusive products!

Some examples of inclusive product features include emojis with skin tone variations, accessible design, gender-neutral content/language.

Some of the product features that put out an invisible sign to certain groups saying “You are not welcome here” include – largely male icons, stereotyping of genders/races, platforms that don’t do enough to prevent/block hate speech/bullying etc.

 

Internationalization –

When we build our products in a way that enables people from all over the world to use our products, we have nailed internationalization. There are certain product features that we may want to “localize”. These need to be conscious choices we make in our product.

When our products have multiple language options, less use of region-specific slang, neutral iconography, precise & literal language that’s easy to translate, we make it available for global consumption.

When our products use country specific icons/metaphors, when we don’t leave enough space for translated text, when we make not-so-global assumptions in our calendars, we are losing so many of our potential users.

 

Sustainability –

If our product features take into consideration the impact we have on the environment, if we strive to reduce our footprint and to promote sensitivity towards the environment, we are building environmentally sustainable, green products.

What can we do to make our products greener? We could add indicators showing the energy impact we have with every action we take on our product. We could make design decisions which use less energy (like queuing of messages etc). We could avoid making unnecessary internet connections. Some of the popular crypto-currencies are infamous for their impact on the environment. We could look to the greener alternative crypto-currencies to learn how they are mitigating the impact on the environment by relying on greener fuel alternatives and other methods.

Now that we understand Why these aspects are important and What they are, let’s take a look at How we can help.

What are some of the things we can do to build such products with a heart?

1. Create more diverse organizations – As our organizations become more diverse and inclusive, our products will reflect this diverse and inclusive nature as well (very distant cousin of Conway’s Law)
2. Create diverse User Personas – We should create a variety of User Personas that we want to cater to and ensure our product features welcome all of them
3. Talk to our diverse Users – What’s even better than User Personas is Users. Let’s go talk to our Users and get feedback from them to organically build more inclusive products

 

Coming to the world of Agile Product Development, approaches to Product Backlog Management to promote these features:

1. Create specific Backlog Items which are related to Accessibility, Inclusivity, Internationalization and Sustainability. These can then be worked into the product when these backlog items are picked up for development. This is a fairly initial stage of addressing these issues. Such backlog items may frequently be traded off for other features which focus more on profitability.
2. Add some of these aspects into the Acceptance Criteria of some of the Backlog Items. This way, when those product features get done, they will only be accepted as done when they also take care of these humane aspects.
3. Add these aspects into our team’s Definition of Done. This, then, is simply how we work. Any item in the backlog can be considered done only when it meets criteria related to Accessibility, Inclusivity, Internationalization and Sustainability. This is a very high level of maturity and is usually possible only in organizations which value Social Responsibility as much as Profitability.

 

It is very tough to create such thoughtful products. But we need to start taking baby steps in this direction. If we don’t crawl, we may not walk. If we don’t walk, we may not run.

If we don’t run, how are we going to fly?

 

Some of the slides related to this topic are available on my Slideshare at –

Does your product backlog include these from vinaya muralidharan

 

and

User personas to promote human-centric product development from vinaya muralidharan

Weathering the Storm

Tuckman’s model overview

Bruce Tuckman’s model is one of the most frequently cited models of group development. It describes 4 nearly linear phases – Forming, Storming, Norming and Performing. A fifth stage was added later called Adjourning.

Forming – This is when the team is put together. People are new and trying to learn about each other. They also trying to learn more about their tasks. The focus is usually still on themselves as individuals rather than on the team. At this stage, team members skirt around tough, controversial topics.

Storming – In this stage, the team members start to broach topics that lead to potential conflict – like structure, distribution of responsibilities, leadership and decisions. This stage is also where team members try to establish their status within the team.

Norming – When teams emerge from the storming stage, they enter the Norming stage where they begin to identify with the team’s common goals. Team members begin to accept each other as they are and display more tolerance.

Performing – With roles and norms established, teams may reach a high level of success. Motivation levels are high and so is expertise due to experience and team stability. Dissent expressed in constructive ways is encouraged.

Adjourning – As the project ends, the team breaks up or disbands in the adjournment phase.

Are you caught in the Storm?

Kanban – A New Hope

The Kanban method to change is great. It is humane, it is doable and the changes are pulled in instead of pushed in. The focus on visualization, improvement of flow, continuous inspection and adaption are all appealing. But can this very approach to change which is the strength of the Kanban method also prove to be a weakness?

Kanban – A New Hope (Part II)

Read Part I here .

Lea’s long and strenuous fact-finding mission was at an end. She was tired but also brimming with a new found energy. Not only was she armed with facts about what didn’t work the last time around, she also had several new ideas about what to try differently going forward. She had met several sympathizers of the resistance and they had all enthusiastically shared ideas and had promised support. And she had in return given them new hope that Kanban would make a comeback.

One word summarized what she had discovered – Momentum. This second wave of Kanban wouldn’t be defeated by Stagnation, she vowed.

As she waited outside the CTO’s office to deliver her report, she organized her thoughts.

Kanban works – she knew that. The approach to change was gentle, humane. She had to be careful not to hurt the core of this thinking.

The suggestions in her report were all complementary to the Kanban method. They were more like boosters and enablers. “I have a good feeling about this”, she thought to herself.

Just then the CTO stepped out of his office and with a smile beckoned her in.

She stood up gathered her notes and walked in confidently. The charismatic CTO was just the partner needed for this program to succeed.

“Welcome back Lea! It’s been a long journey for you.” – Said CTO .

“Yes Mr.CTO. I have learnt so much. And my faith is stronger than ever.”

“That’s heartening to hear. Spill it.”

“Well let me start with what was ailing our earlier implementation. The problem was not entirely with Kanban or the Kanban method. But after a point stagnation set in. We lost momentum. We had some ground level support but we weren’t able to mobilize it. Somewhere we lost the plot.”

“Well, I did have my suspicions in this direction. But are you sure Kanban is a good fit for us? You know I am a pragmatist. I cannot afford to indulge intellectual fantasies. Galactic cannot afford it.”

“I assure you, my fact finding was completely objective. I sought out the naysayers and that’s where I learnt the most from. So my report is pro-Kanban but it is based on very sound reasoning.”

“OK. Let’s hear the suggestions you have.”

And Lea presented her get well plan

“

1. Quick wins – The Kanban method recommends starting where you are, take small steps, retain existing roles. This is great and we need to continue doing this. But we also need to start right. We need to target places where we have higher chances of gaining small successes. Building up this momentum is crucial for it to become something more people will want to try. And then we need to declare the small victory and celebrate. This positive reinforcement done publicly will gradually build enthusiasm for the change and will attract the late majority. The story to paint and share is “Hey look we did something that worked for us. Its small, its light. Why don’t you give it a try too?” A tipping point where more and more people are trying small improvements needs to be reached – a point from where sliding back to old ways is tough.

2. Visualization of the change – One of the most popular aspects of Kanban is the power of Visualization. We need to use this same powerful thinking about Visualization to promote the change as well. Since the changes in Kanban happen in small steps, people may not notice the change. The fact that progress is happening slowly but surely needs to be made very visible – impossible to miss. Big Visible Information Radiators about the change program itself need to be established. Whiteboards, televisions, big charts employ every media at our disposal. Metrics, reports, improvements, failures – all transparently shared can be a surefire antidote to complacency.

3. Management support – While our Kanban implementation saw great ground level support – Personal Kanban was a great parallel movement – a change as fundamental as this must have explicit management support. We need our senior management and leaders to participate fully in the change. We need them to invest time in understanding it, talking about it and trying it. When the time comes to take some decisions which pit the new and old ways against each other, they need to make the right choices – people are watching them. People are watching what they do much more that listening to what they say. As agents of change, we must bring our leaders onboard.

 

4. Moving beyond the initial stage – We did well last time setting up visual boards and introducing new metrics. And we thought this was it – transformation done. But every time the visual board showed us a challenge, our response was to ignore the problem or blame the method. The fact that our implementation barely scratched the surface is a symptom of deeper problems. They point to lack of commitment and conviction to the real change. Going forward, we must consciously use every challenge we face as an opportunity to pursue small, incremental improvements. We could device small experiments for improvements, inspect the outcomes and adapt. Looking for a lot of predictability is probably a fallacy. Accepting that we will need to Probe, sense and then respond is important for us to make progress. Looking to what the industry is doing for technical excellence, for process improvement, for improvement of flow will give us ideas of what to try. Encouraging everyone to participate in the improvement journey will unleash the real potential of our people. But first, before all else, we must start experimenting with WIP limits.

“

“That sounds like work but it is something we can definitely do! Anything else?”

“Yes, there were many things we did well in the past – we must continue to do those. Whether it was our parallel promotion of Personal Kanban, or the establishing of new metrics or the publishing of the formal big case studies – these are things we must keep doing and do even more.

We have supporters, we have non-believers. This healthy dissent is going to help make our cause stronger, better!”

“One final important thing for me to share – a summary of what we can do to stay true to the Kanban foundational principles in our environment:

Kanban foundational principles	The unsaid bits
Start with what you do now	And respond to new information that comes to light
Agree to pursue incremental, evolutionary change	And pursue it surely and visibly
Respect the current process, roles, responsibilities & titles	And be open to inspecting and adapting them gradually

“

“Lea, you have done well. You have my backing. I will get you a meeting with High Towers. I would recommend having something more visually impactful and concise for the meeting with him.”

“Thank you Mr.CTO. I will make the most of the meeting –  a causal loop diagram supporting the findings and recommendations should help present the case better! Not only that I will have concrete examples of what to try immediately as a kick-start.”

“That sounds promising. All the best!”

With that, Lea smiled, and walked out with her head held high, with a renewed spring in her step towards a brighter future!

Why start with Why

In a small village in India, every morning at 7 AM the villagers would gather at the local temple to offer prayers and perform various rituals for the local deity. Before doing so, however, they would look for a cat, and tie it (gently) to a tree outside the temple. Once the prayers were done, they would let the cat go. This had been going on for years.

Once a traveler was passing through the village and he observed these events – the search for a cat, typing it to a tree, offering prayers, releasing of the cat. The whole cat routine aroused his curiosity. He felt sure it had a deep spiritual message. He asked one of the villagers why they did that. The villager said that that’s how it has always been. Not satisfied with the answer, the traveler asked another villager and got the same answer. The traveler was still curious and sought out the oldest person in the village, who he was sure would help him solve this riddle. And finally he got the answer he was looking for.

The elderly villager said “Many years ago the priest of the temple (who has since passed away) had a pet cat. Every morning, when the priest would be about to start his prayers, the cat would run around in the temple and get in the way of the priest. So to be able to go about his rituals uninterrupted, the priest would take his pet cat outside, tie it to the tree outside the temple, finish his prayers and then untie the cat.” Mystery solved!

I think the message of the story is clear – understanding why we do what we do is much more important than what we do!

The villagers in this story had observed the practices of the priest and followed it very well. But they never understood why the priest did what he did. It could have saved them a lot of trouble – after all catching a cat everyday can’t be easy to do.

The same goes for Agile adoptions. The journey of Understanding must start with “Why” before going on to “How” and “What”. Once this understanding exists, it may be that the implementation starts with a focus on “How” and “What” with “Why” forming the backdrop.

 

What happens when we adopt practices but our implementations are not rooted in values, principles, beliefs, philosophy?

1. Change management becomes much tougher than it needs to be. Unless one is an extremely charismatic leader whom teams will follow blindly, one needs to be able to articulate and clearly communicate Why we are doing What we are doing.
2. Not having strong foundations based on values leads to inconsistent decisions and confusion. Without values and guiding principles, decisions are likely to be merely reactions to local, transitory events.
3. It limits our adaptability and agility. If we are faced with a new situation which makes earlier practices invalid, values can guide us to come up with relevant new practices.
4. Balancing autonomy and alignment is tricky. Alignment on values and autonomy on practices can help strike the right balance.
5. By simply emulating “best practices”, we may end up adopting a lot of practices. But unless they answer the “Why” question, many of these could just add to our overheads without giving us any returns. By being clear about the Why, we can pick and choose and design what suits our environment best!

Always start with Why!

Without your why you will never know how ~Anonymous

Explaining Flow – Traffic Metaphor

Metaphors

Metaphors are powerful. We use metaphors in our everyday language without even noticing it. They appeal to the mind since they take new, sometimes complex ideas and relate them to known, every day events/objects. They help create a bridge of understanding by using a shared frame of reference.

Examples of metaphors

“Choices are crossroads”

“Domino effect”

Metaphors are a great teaching tool. In my role as an Agile Coach, I am frequently helping to find ways to improve the flow in the system. Ideas from Donald Reinertsen’s book “The Principles of Product Development Flow”, Kanban and the Theory of Constraints largely guide my thoughts.

However, these ideas are often complex and frequently dry. So I turn to the simplest metaphor I can think of to share the ideas.

Software Development Flow and Traffic as a metaphor

The exercise I do using “Traffic on Roadway” metaphor is simple.

We need to get from point A to point B in our city – what are some of the things that could help us traverse the distance faster?

The answers start coming rather fast since it is an easy metaphor for all to relate to–

• Smooth roads
• Faster vehicles
• Smaller vehicles
• Less traffic
• Green traffic lights
• No speed-breakers/bumps
• Apps showing me the traffic on my route
• Etc

Let’s look at some of these responses and relate them to our software development environment – making this connection explicitly is important.

Smooth roads

Smoother roads help us go faster from point A to point B.

What could this mean in the software development world? Good infrastructure – do our developers have good supporting systems – build tools, testing frameworks, project management tools and frameworks etc. The systems and frameworks, that exist in the background all the time and are used repeatedly, need to be enablers. If they are time-suckers, then we are considerably slowed down.

Faster vehicles

A motorized vehicle will mostly get us faster from point A to B than a bicycle.

Similarly having the right tools, the right skills helps us get work done faster and with the right quality.

Smaller vehicles

Smaller vehicles like motorbikes usually go faster than bigger vehicles – they can slip in through gaps and beat the traffic. Also a motorbike needs to wait for no one whereas a public transport bus would need to have a reasonable number of passengers to be economically viable, needs to wait for various passengers to board etc.

In the software world, this relates to smaller batch sizes – smaller user stories, smaller features etc. Since they are small, they are lighter and quicker, they usually flow faster.

Also independent small work flows faster than big batches of work (Motorbike Vs Public Bus). If early feedback is more valuable to us than the cost of overheads, we need to make our batch sizes smaller.

Traffic control

Special lanes for certain types of vehicles like buses (Bus Rapid Transport Systems) or blocking heavy trucks on certain routes during peak hour or having special toll routes – all improve the flow of traffic (if implemented well).

Similarly, if we limit our Work In Progress, create special Expedite lanes, say No to some work items, then we can significantly improve the flow of work.

Traffic Apps

Apps that predict and update local traffic conditions are a great way to avoid bottlenecks.

Similarly information radiators, fast feedback, visualization of where work is getting stuck are great ways to manage our work and increase of chances of completing work soon.

Roundabouts Vs Traffic Lights

Roundabouts let drivers self-manage as against traffic lights (a centralized, static system)  which create a stop/go flow of traffic – roundabouts help keep the traffic flowing and smooth. However, roundabouts demand a shared policy/rules between the drivers and also a high adherence to the policies.

Similarly at work, external centralized decision-making and control slows things down. Empowered, responsible teams are closer to the work and are able to respond faster to change and take decisions quickly.

Preparing for the journey

Starting your commute with good readiness – fuel, condition of the car, knowing the route etc – gets you to your destination faster.

On similar lines, having a definition of ready and preparing and planning, increases our chances of foreseeing risks, avoiding some impediments and having a smoother workflow.

In the preparation for the journey, it is important to assume that there will be uncertainties and variabilities. It is best to defer decisions to the last responsible moment (LRM) so as to take decisions based on the most information you have.

Speed-breakers, pedestrians and other impediments

Having fewer speed-breakers, crossings etc make the road smoother since there are fewer interruptions.

Similarly minimizing interruptions and waste helps work get to done faster. Managing and minimizing these is a big part of improving flow. Surfacing issues and resolving them quickly is an important capability to build.

Disruptive ideas

The best part about this exercise is when people break all the rules and start thinking of wild ideas.

Like using a Helicopter. Or teleportation…a la Star Trek.

These are great opportunities to discuss new possibilities, to discuss overheads of expensive ideas vs value of throughput and many others.

In Conclusion

Understanding what impacts flow, and how, is very important for modern project management. Using simple metaphors for the system help us grasp these ideas and concepts easily.

The trick is to know how to translate back from the metaphor to the project environment.

Find the right metaphor, make the connection clear and explaining new ideas and concepts is as easy as (Metaphor Alert!) taking candy from a baby.

Perspectives on Continuous Integration at Scale

The word Enterprise conjures up images of big multi-million projects, thousands of people working together, distributed locations, complex products, multiple modules, projects impacting millions of users and mission-critical systems.

All of these are true for our environment.

This is the environment where we have successfully started our Continuous Integration journey and are enjoying great results.

When we embarked upon a journey to modernize and streamline the way we developed software, it was a daunting task. And the change was huge in all aspects – People, Technology, Processes.

But the results are very heartening. From being able to clone environments within minutes, to reducing build times from days to hours to the ability to deliver to customers frequently – we are experiencing the benefits every day today!

The road was not easy. Being a Service Delivery organization, and not Product Development, in itself posed a huge challenge. On top of that we were working with multiple products, multiple technologies and multiple specializations, with integration as our top issue to solve for years. Legacy source control and build systems limited our ability to learn from the industry.

We frequently worked on mega transformation projects for big Telcos. These were always multi-vendor environments demanding heavy upfront planning.

With the multi-product and super-specialization environment, our teams were component teams and not feature teams.

Against this backdrop, we undertook our Continuous Integration journey over 3 years ago.

Technology was our first stop – modernization was kicked off on several fronts – version control, builds, artefact management and test-automation framework. Our new technology stack (including Perforce, Maven, Nexus, Sonar, Jenkins) relied a lot on open source – we learnt from the collective knowledge of the industry!

Process – We supported the technology upgrade with lighter and more agile processes. We cut down on bureaucracy and focused instead on getting to working integrated software quickly and transparently.

People – People took center-stage in this transformation. Developers started being viewed as more than mere resources – we started acknowledging our craftsmen! The sphere of influence and impact of our developers increased and they were ably supported by new tools, processes and technology.

The change was huge and it wasn’t easy. We made a few missteps along the way but we are continuously learning and course-correcting.

Our developers had to learn new ways to code, our approach to metrics had to undergo a re-haul, collaboration between teams took on new significance and middle-management was recruited as an ally!

Many large enterprises may face similar challenges and we would love to share our experience with more people, to assist in our small way, in their transformation.

We have come a long way – however we have much longer to go.

We are already doing several proofs of concept in areas including security, deployment and automation.

The future holds many promises!

Come hear us share our experience at XP Conf India 2016

Written by Hrishikesh Karekar (@hrishikarekar) and Vinaya Muralidharan (@vinaya1980)

 

Trees – Some of my favorite thinking tools

As a coach, I frequently find myself facilitating discussions – either in root-cause-finding missions, or weighing alternatives or trying to translate ideas to action items.

I draw upon some popular thinking tools which I think have universal appeal and I would like to share those here. Hope you find application for them too…

The WHY tree

This is something I have been using in some format or the other for years now – either as 5 Whys or the Ichikawa/fishbone diagram. It is a great way to determine root causes for visible symptoms. The WHY tree that I usually draw, is similar to the Ichikawa diagram but drawn as a Tree (Go Green!).

 

The SO tree

This is an approach I have started using more and more recently in my attempts to influence change – to help people see what could the impact of their current actions be and to try and help them discover the need for changes.

Another more common application is probably to see the impact of some significant decisions being taken on the overall system.

 

The HOW tree

While the WHY and SO trees are critical tools that I use for analysis, the HOW tree is action-oriented.

We end way too many meetings and discussions with great insights and analyses but woefully lacking in real action and outcome.

The HOW tree helps translate great ideas, thoughts and insights into action items.

 

And to end my blog, here is an extremely fictional (and simplistic) application of these trees 😉

 

Try something new today!

Agile embraces failing fast and failing often.

Sounds like something losers would say, huh?

After all, most of us have been conditioned since childhood to work hard in order to succeed.

So how does one embrace failing?

The secret is to fail fast and often but also to fail small and cheap.

And, of course, to learn fast and often from these little failures.

So here’s what i am trying –  doing small experiments and learning from them – with a visual board.

Failure (and Success) in full view

Step 1 – You have an idea – log it

No idea is too big, small, bad, crazy, wild…Everything goes on the board

 

Step 2 – Design a small experiment to try your idea out

Questions to ask yourself –

What will I learn if the experiment succeeds?

What will I learn if the experiment fails?

Is the experiment cheap enough?

Is the experiment small enough to recover from quickly if needed?

How will I know if the experiment failed or succeeded?

Step 3 – Run the experiment – keep it small, fast, cheap

Step 4 – Experiment done – what did we learn from the experiment?

Step 5 – Done (Experiment Succeeded/Experiment Failed)

Rinse and Repeat for other ideas!

 

Agile Maturity Model – create one in 4 easy steps

Maturity models are frequently used as tools to help assess a process or an organization.

In Agile implementations, it is not uncommon to use check-lists, health checks, maturity models with a similar goal in mind.

Why are Maturity Models useful?

Agile implementations, or similar big fundamental changes, to the way we work, take time. While we start with some desired state in mind, we usually evolve to that stage over months and sometimes years.

Having a maturity model or a similar tool helps us look at the big picture, to see areas where we are making good progress and areas which need more TLC.

Maturity models are also a great way to keep the end (-ish, because the journey doesn’t really ever end) in full view for all. It shows what we are gunning for.

Building a Maturity Model

While a maturity model may actually assess process maturity, it is important to have the outcomes as the primary focus.

This way, even if our process or practices change, we can still use the basic framework of our maturity model which is based on outcomes.

For instance, if one of the reasons for doing an Agile Implementation is to improve the team’s ability to respond to change, then we would like the maturity model to show how the team is maturing in “Responsiveness to Change”. Or if delivering high quality software is a desired long term outcome, then we would like to visualize through the maturity model, how far along we are in the journey in “Quality”.

So, step 1, is to pin down the desired long term outcomes we are trying to effect through the Agile implementation.

So the outline of the maturity model after this step may look like this, for instance:

 

Once we have the outcomes pinned down, we need to actually build the questions using which we can assess process maturity – towards our outcomes.

For instance, if the team believes that Pair Programming improves the Quality of our software, then the maturity model may have a question asking specifically “Does the team use pair programming regularly for writing code?”

Or if the team works in short sprints to make us better suited to respond to changes, a question like “Does the team work in sprints that are 2 weeks or shorter?” may find place in the maturity model.

So step 2 is to figure out what are the questions that help us assess the process maturity which helps us make progress towards the outcomes we have in mind.

So the Maturity model at this stage may look like this:

 

Now comes the “maturity” part of the maturity model.

A maturity model recognizes that change takes time and process maturity evolves.

How a team behaves when starting with an Agile implementation and how an experienced team behaves, are vastly different. So the questions in the maturity model need to reflect this growth in maturity.

So step 3 is to take the questions and order them by “maturity”.

For example, a new scrum team may simply start having daily scrum meetings as a practice without fully extracting the value from it. So a question about “Does the team meet daily for a 15-minute daily scrum meeting?” may be appropriate in early days. But as the team matures and learns the value of the ceremony, a more relevant question might be to ask “Does the team challenge and improve the process of the daily scrum meeting?”

For each of the outcomes identified in step 1, we would have a list of questions ordered by maturity.

It also allows us to categorize the questions according to maturity – for instance “Beginners”, “Experienced”, and “Experts” or similar.

How do we score the questions? We keep it simple.

We design “Yes or No” questions with a score of 1 for Yes and score of 0 for No.

This now helps us identify where on the chart we would be if we answered yes for all the “Beginners” questions, and so on.

The maturity model may look like this at this stage:

Finally …Color codes and their significance

Visually, it is important to color code the stages of maturity. However we do not want to fall into the RAG (Red-Amber-Green) trap.

Being a beginner is not a red status – it simply shows where we are in the journey.

So we use any colors, other than the RAG scheme (or schemes with similar connotations) and keep any misinterpretation of the model at bay.

Here’s the maturity model in its full color and splendor:

 

Maturity Model Do’s and Don’ts

Often, a well-designed maturity model can be defeated by poor usage.

Here are some tips to using one:

1. Use it frequently but don’t overdo it – so once in 2-3 months, just before a retrospective is probably a good place to assess the maturity. The maturity assessment can be a great input for the retrospective.
2. Answer the questions together as a team with a facilitator helping you discern the questions when required. This is also a good opportunity for the facilitator to improve the teams’ understanding of the process and to show the end goals to the teams (give them something to aspire for).
3. Use the maturity assessment outcomes to find the areas needing extra attention and look for improvements there.
4. Do not use it as a governance tool for management – management may however look at accumulated trends across the organization to draw improvement items for them to act upon.
5. Do not use it to evaluate or compare teams – every team is on their own journey with their own contexts, strengths and constraints.
6. Don’t sweat the details – exact scoring, minute variations etc do not matter in the larger scheme so just ignore them.

 

Here’s what a maturity model with assessment done may look like:

 

So in summary, here’s how to build an Agile Maturity model:

1. Step 1 – Identify the long term desired outcomes
2. Step 2 – Identify the practices that help us go towards our desired outcomes – translate them to simple “Yes/No” questions
3. Step 3 – Order the questions by maturity levels and group them
4. Step 4 – Have a clear visual representation of your maturity model and assessment

Building an Army of Volunteers

Kotter’s new Accelerate model

In John P. Kotter’s new change model – Accelerate! – he talks about how promoting the change through established hierarchies alone can actually be detrimental for modern organizations.

He talks about the existence of the informal strategy network – a flexible, adaptable structure that is populated with employees from all across the organization – up and down its ranks.

And he proposes a dual operating system for driving change – a management-driven hierarchy complemented by the strategy network!

So the approach is that of “and” and not “or”. Both, the hierarchy and the network, have a role to play.

What is a volunteer army?

“Many people driving important change, not just the usual few appointees”: Kotter’s vision is to attract a “volunteer army” of employees from the informal strategy network who buy in to the message of change and are committed to it, an army of volunteers who participate actively in problem solving, innovation and collaboration.

Why do people volunteer?

Before we start looking for ways to build this volunteer army, we need to understand why people volunteer.

Think about the last time you volunteered for something – at work or outside of work. Think about why you volunteered.

Did you do it since it provided you an opportunity to learn?  Did it give you a sense of satisfaction? Did you do it as a favor to someone?

Broadly speaking, people are motivated to volunteer by one of three reasons –

1. Self-serving drive – what’s in it for me?
2. Relational drive – because “xyz” asked me to …
3. Belief drive – I am passionate about the cause

What Kotter says about getting volunteers?

Kotter’s tips on motivating volunteers stress on creating a feeling of the volunteers “getting to” do something rather than “having to”. Also appealing to heart and head is more likely to get us results than appealing to logic alone.

How to recruit volunteers

How to recruit a Self-Serving Volunteer?

Target this group by helping them answer questions like:

1. Will I be seen as an expert by doing this?
2. Does it make my resume more attractive?
3. Does it help me grow?

So incentives like certifications, awards, skill-building, opportunities to share new knowledge publicly and others may work here.

How to recruit a Relational Drive Volunteer?

This is largely driven by the recruiter’s personal networking skills and how much s/he invests in these relationships – it takes time and effort to build such relations.

How to recruit the Believers?

1. Talk about the Why instead of the What or How
2. Don’t expect full alignment on How
3. Be completely transparent with this lot – about benefits and shortcomings of the change

Consult them in designing the solutions

Finally, for all volunteers –

Make volunteering easy!