Why agility stumbles at Daily Stand-Up?

Of late, an all-too-common trend in Scrum has become hard to ignore. There is a rush to ‘give status’ in the Daily Scrum meeting. Try calling someone and you would invariably hear ‘can I call you back, I have to give status in the Daily Scrum’. People send emails giving the status update for Daily Scrum. Interestingly even those who don’t practice Scrum never forget to give status in Daily Scrum.

Unfortunately, it is followed so widely that almost everyone believes that it is ‘normal’ to give status update during Daily Scrum?  But is that the real intent of Daily Scrum? The simple answer is ‘no’.

The Scrum Guide says “The Daily Scrum is a 15-minute time-boxed event for the Development Team to synchronize activities and create a plan for the next 24 hours. This is done by inspecting the work since the last Daily Scrum and forecasting the work that could be done before the next one”. The intent is for the team to look at their forecast, and discuss either how to get back on the track or plan for an early redemption. They need to identify the goal and discuss if it is the right approach with all the right folks to accomplish that. If they need help they are entitled for help as well.  Daily Scrum is a daily need. The idea is to inspect and adapt. In fact, just by attending a Daily Scrum you can tell if the team is really agile. It is all about mindset of your team.

So why do people provide status update in Daily Scrum?

Probably the first reason is the set of three questions suggested in the Scrum Guide.  The intent behind those questions are clear – achieve the goal or sub-goals for the day, but the suggested format makes it sound like it is driving status communication. People day after day just answer three questions and completely miss the real intent behind those three questions. Sometimes I feel if the guide were a little less prescriptive, it could have served the Scrum community better.

The other reason is the project-oriented approach in Scrum. Since people think they are working on a project with an end date, they need to provide status. Obviously they are not working to meet goals, or sub goals every day; they are working to complete a project so they find it worthwhile to provide status vs inducing creativity to meet the goals.  It’s the mindset still catching up with the reality.

The last not the least is the status-seeking business stakeholders, the tribe which has taken the back road in adopting the agile mindset. They do not set the goal for the team and when team becomes goal-oriented they just don’t get it and start ‘managing’ the team. This stifles the growth mindset; team implodes and starts reporting status to keep the stakeholders in good humor.

– See more at: http://blog.scrumtotal.com/why-agility-stumbles-at-daily-stand-up/#sthash.xtKCJW7t.dpuf

Emerging trends in agility subtly redefining business environment

Someone said, ‘Evolution does not care whether you believe in it or not’, and that is true for Scrum as well. Scrum and all agile practices are evolving. Recently I got to read the opinions of leading agile experts on various aspects of Scrum/agility (presented below as ‘other experts’). At the same time, I see some remarkable changes in the world of agility are rapidly redefining today’s business environment. Those who can negotiate the rapid pace of change, anticipate the needs, and take the lead in developing the right culture and strategy for the future are likely to be winners.

Agile is team focused

Common Belief

Agile is a team-based approach.

Other experts

One must look at the entire value stream – from product management to the team. Product management in many ways is more important than the teams themselves as you must be building the right things and have the right workload.

Emerging trend

Instead of creating a value stream, create one team which would be a combination of business stakeholders, and Scrum team. Smaller end-to-end teams deliver better results. The team should create a cutting-edge product backlog, work effectively, and deliver killer products asap, every Sprint.

Scaling Agile

Common Belief

Scaling Agile should start at the team level.

Other experts

You don’t want to scale Agile, you want to look at the entire value stream. Smaller teams working together is better, but if you have to work at scale, start by looking at the entire value stream. Starting with effective product management is often much more important than getting teams to work well.

Emerging trend

You don’t need to scale Agile, you need Microservices. Create small independent teams with shared consciousness having a little or possibly no dependencies. Each team should be able to deliver features independently and be able to leverage the fast changing technology instead of adding to the monolith which slows down the company.

Self-Organization

Common Belief

Agile works because teams get to self-organize.

Other experts

While self-organization is important, it is more important to have an effective eco-system within which to self-organize. This mis-belief is why many things required at scale are ignored in the Agile community.

Emerging trend

The agility does not work in isolation, we need agility everywhere in the organization, not just in the IT teams. We don’t need to scale; we need Agile mindset. Leaders and knowledge workers both will have to create a culture of agility in the entire company for real success.

Scrum of Scrums

Common Belief

Scrum of Scrums works to scale Agile

Other experts

There is little evidence this approach works well. It certainly is not the only way to coordinate multiple teams.

Emerging trend

Scrum of Scrums is the continuation of coordination at the program level to respond to the need of monoliths, it never worked and possibly cannot work. Build Microservices, it works. Stay away from monoliths to respond to the changes quickly.

Scrum works at all levels

Common Belief

It’s all Scrum

Other experts

Inter-team dynamics are quite different from team dynamics. Applying what works at the team level everywhere causes challenges.

Emerging trend

Scrum is just a framework; Agile mindset is need of the hour. Scrum is not a fixed set of rules carved in stone. It should evolve forever. Software is the reflection of leaders’ thought process. Centralized organization structure would create monoliths. Move away from centralized structure and create self similar fractal structure. Work towards distributed independent teams with minimal coordination.

Management’s role

Common Belief

Management’s role should be supporting teams.

Other experts

While management does need to support teams, management has responsibilities beyond removing impediments for the team. They are responsible for setting up the system within which people work.

Emerging trend

Management has an equally important role. Besides setting up ecosystem, they need to explain ‘why?’ and goals of the company; need to create and share the purpose, and they need to promote the right culture with every action.

Continue reading…

5 reasons ‘avoiding’ decisions could make you more agile

Delaying a decision could be a bad thing, but avoiding decisions may not necessarily be a bad thing. In an agile workplace avoiding decisions actually helps in creating an effective team. Avoidance does not mean failing to act, delaying, procrastinating or accepting the status quo. People may also think that it may provide an excuse to not make decisions. However, there is a balancing act between a bias for action and making a decision at the last possible moment. Choosing to make a decision at the last possible moment is indeed a bias for action, just when you need that most.

• Empowered teams make smart decisions and implement them

Avoid making a decision, unless you have a compelling reason, to create an empowered team. By avoiding a decision (as a manager or coach) you are allowing agile teams to make a decision they think is the best. Keep in mind the person who makes a decision, is also responsible to implement it. If the teams make decisions, they will be responsible to implement them. On many occasions managers/coaches are tempted to make a decision on behalf of the team and take the responsibility of exploring ways to implement the decision. That not only corrodes the empowerment, but also sends conflicting signals to the teams.

It is tough, uneasy but avoid the temptation to make decisions, if you want your team to become truly empowered. Many executives still fallaciously think that the principle is applicable on other managers and not on them.

• Development team does not know how to build a solution

The development team doesn’t always know how to build a solution in a most cost-effective way. Typically, they tend to build everything. Software development requires experimentation and growth mindset where people continuously explore, learn and improve. Avoiding quick decisions would surely help the development teams explore more options, possibly the shortest and best route to achieve business goals. It will potentially reduce the likelihood of developing code that will never be used.

Continue reading…

Do you feel empowered? Think twice

In my recent experience, I noticed an alarming trend where many development teams are stretching the definition of a self-organized team a little too far. They believe that they can choose what they want to work on the backlog, they can tweak the framework (if they think the framework does not ‘suit their convenience’), they can decide the length of the Sprint or in Kanban choose NOT to have WIP, Cycle Time and the list goes on. Literally they feel empowered to ignore almost all the principles of agility, and fundamentals of Scrum/Kanban. Any effort to mentor them meets the common refrain – we don’t need be dogmatic, idealist, or follow Scrum by the book. But a few realize that self-organizing teams need subtle control to be functional.

The Scrum Guide says (about the development team)…  “They are self-organizing. No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality.”

But what propels the development team to take the control?

It is a long list but one primary factor is organizational dysfunctions. A development team’s ultimate desire to meet the business goal doesn’t excite them to pick another battle against organizational dysfunctions. When they are not able to overcome the dysfunctions they tend to tweak the framework to accommodate the dysfunctions. Another factor is the pain of learning. Agility is a socio-technical phenomenon which requires a change in mindset. It is built upon learning and continuous improvement. Avoiding the pain of learning whether it is learning cross functional skills or value of effectiveness over efficiency, the development team often tends to follow the path of least pain and if that tempts them to tweak the framework they succumb to the temptation.

Subtle control vs empowerment?

In the The New New Product Development Game, Takeuchi and Nonaka talks about subtle control. “Although project teams are largely on their own, they are not uncontrolled….. At the same time, management avoids the kind of rigid control that impairs creativity and spontaneity. Instead, the emphasis is on “self-control,” “control through peer pressure,” and “control by love,” which collectively we call “subtle control.”

Continue reading….

7 tips to curate innovation culture

Product owners or executives always look to wow their customers with innovative product/services, more delightful than possibly expected. They all want an innovative workforce but a few know how to get that by curating the culture for innovation. Innovation is a group activity, a psychology of creativity, that cannot exist in isolation. Innovation is hidden in your day to day work, not in labs. Look for these seven factors to curate/inculcate innovative workforce.

1. Individual styles of thinking with a difference – Individuals are creative when they adopt a problem-solving approach that differs from their typical style of thinking. Encourage your people to challenge status quo and practice the reverse logic.
2. Promote a culture of failing and failing often – Enjoy getting out of red more than watching green. Eagerness to solve the bugs in prod (not deliberate) vs having no bug.
3. Make them feel you care – An individual perceives that the company or coworkers care for him or her, which cultivates psychological conditions such as safety, security for innovation.

Continue reading