Category Archives: Adoption

3 Pillars of Scrum – Core but easily forgotten

Screen Shot 2016-07-17 at 8.03.49 AM

What are the 3 pillars of Scrum? This is a one question I love to ask leaders, Scrum Masters, Product Owners and members of development teams as I engage with them, trying to help with their agile adoption. The statement “our team is already agile” is commonly heard but what is being referred to is the fact that the teams are conducting Scrum events (sprint, sprint planning, daily scrum, sprint review and sprint retrospective), connecting these events to agility and keeping the ideas of transparency, inspection and adaptation on the side.

Limiting the idea of agile adoption to just events and practices is a clear indication of the missing understanding of the core mindset of agile and Scrum and instead, the use of Scrum as a process control method.

The simplistic design of Scrum framework and the embedded practices are the heart of creating a agile culture for software development. Every event in Scrum is conducted to constantly put the 3 pillars of Scrum in practice to not only ensure adherence to the framework and its practices but also to have agility embedded to the people and process aspects of product development.

Most common examples of situations when transparency, inspection and adaptation are overshadowed by other “not” important decisions are:

– What is the buffer we should account for during the sprint to account for unplanned work? This is a step in the wrong direction from a transparency perspective. Team should rather allow for unplanned work to impact work so that delays become visible and the team can assess the reason behind unplanned work and adapt by working with the Product Owner to make the right decision.

–  Our/Your burn down does not look good. This is commonly bought up as an issue by the Scrum Master or the management and can take the focus of the team from getting the sprint forecast accomplished to making the burn down look good. It is important to understand that the burn down was not created to paint a good picture of the team but to transparently surface delays so that the team can collaborate and plan for the work to be done to possibly meet the forecast.

– Get the stories to “done” by moving the undone tasks to a new story. The “Definition of Done” is sacred to the team and is created with an intent of ensuring that the story accomplished is in a state to be released into production. However; creation of new stories with an intention of claiming browny points for work done or delaying defects for later is a common cause of delays and reduced quality.

There are many such behaviors and conversations that you will observe in your teams and the easiest way to make the right decision is to go back to the 3 pillars and make a decision keeping them in perspective. This is what I do while coaching team and it is what teams should do to create a culture of agility.

Remember, Scrum does not solve problems, it exposes them

Agile transformation – Working with shared services along the way

Screen Shot 2016-07-05 at 1.27.38 PM

The concept of shared services is prevalent in most large organizations. A centralized user experience or architecture group or services group can be commonly spotted. A lot of times, component team setups are given a flavor of shared services.

No matter how much dysfunction it causes, shared services continue to live for many reasons including:

  • Organization’s inability or hesitation to make structural changes
  • Fear of being exposed in getting outside of their comfort zone
  • Fear of change in general
  • Focus on local optimization
  • Others…

The fact remains that shared services are generally not economically viable due to associated communication overheads and increased cycle time to get work done, however; the idea of shared services will not go away anytime soon. So what are some of the ways to work with shared services setup in an agile organization? Saying that organizations need to completely change from a shared services structure to feature teams capable of delivering end to end functionality will sound lame and unrealistic. Below are some techniques that can help organizations work with shared services, trying to transform to the agile way of working:

  • Vision – The environment in a shared services setup is generally chaotic as consumers always have a high priority need. At this time, it pretty much becomes a bidding game. The person or team that shouts the loudest or the person with the highest level of influence is able to get their work prioritized to the top. This is followed by the lengthy process of knowledge sharing where the member of the shared services team spends time in understanding what to build and why. This causes the shared services team member to take a very narrow approach to quickly build what is being asked without understanding the vision and move out to the next ask. This sounds pretty much like a robot in a manufacturing environment that just gets its work done without caring about the end result.

vision

For agile teams, having a common understanding of the vision of the overall product or just a single release is of paramount importance to ensure that every single activity is focussed on achieving the vision. When working on large product backlogs, it is recommended that teams (I mean the whole team and all the teams) get together to create a common understanding of the functionality targeted in the next release. All teams involved should participate and help in sequencing the work to be done to be able to assess when the consumer will need something. This generally calls for investment of time from all teams but the outcome overshadow the cost.

Where there exists a clear vision and a clear understanding of what is needed from the teams, team members remain excited about what is being developed and look forward to their contribution and stay engaged

  • Alignment“Change is the only constant”. A sequenced backlog should not be treated as a project plan. Once a vision has been established and the backlog has been sequenced, all involved teams should come together on a regular basis to inspect the progress and resequenced their backlog as needed. Four-Dimensional-Goal-Alignment

This will specially help the shared services    teams to reprioritize their work to make sure that the next highest priority deliverable goes out quickly.

  • Collaborate – Coming together frequently to align is part of collaboration. Additionally, having someone from the shared services team attend the consumer team’s daily Scrum and other Scrum events and vice versa will help both the shared services team and the consumer team to stay informed about the progress being made and plan their work appropriately.
  • Service Level Agreements (SLAs) – Achieving discipline through working agreements is important when it comes to collaboration between teams. To use a metaphor, car manufacturers rely on multiple suppliers to provide various parts of the car to be able to assemble the end product. Each of the suppliers have to agree to certain processes and protocols to make sure that the assembly line does not come to a halt due to shortage of parts. Each part has a assigned reorder inventory level at which point the order system automatically places order for the next shipment. 3771.PPP_PRD_165_3D_people-Binding_Agreement_1FA08461Not only is the vision of the system clear to each supplier, the suppliers ensure delivery of products on time and are also liable to penalty if the agreements are not adhered to.

The key focus agreements is to build the environment of collective ownership, collaboration and focus to ensure quality and timely deliverable while maintaining a flow.

  • Use a tool – Tools can come in handy when it comes to collaboration and keeping shared services teams informed about their commitments. While I am a huge proponent of physical boards for Scrum teams, I do have to acknowledge that physical boards become a limitation when trying to keep shared services teams informed about the needs or the change in needs of the consumer.

tool-icon

Additionally, tools can be used by teams to generate metrics to assess their performance in being able to meet their SLAs, get notified about key milestones and provide data specifically targeted towards continuous improvement.

 

————————————–

While I truly believe that structural changes are a critical part of a successful agile transformation, it is not always possible  right from the word go. Organizations are generally resistant to radical changes fearing impact on running the business. While baby steps are taken to impact structural transformation, the above mentioned steps will help in the interim to help the organization get started on the journey of agile transformation.

If you have other ideas/techniques that you have used in your engagements, I would love to hear from you.

 

 

 

 

Have you read the scrum guide lately

Screen Shot 2016-05-24 at 4.21.31 PM

Every conversation around agile and scrum is a conversation about empirical process control. The term empirical is derived from or related to experimentation and observation rather than theory.

You must be thinking what has this got to do with the scrum guide. Well, there is a connection.

When experimenting, a big part of the experimentation is based upon the rules of idea or a entity that is being experimented with. As a example, when experimenting with chemicals in the lab, there are clear rules on when a chemical compound can increase risk or be harmful. However; scientists and researchers have continued to study chemicals from the time they were discovered to now to explore opportunities to leverage the properties of the chemical for general well being or further analysis. The study never stops.

In a similar way, some of authors who wrote some of the world’s bestsellers have continued their research, aspiring to make the results of their research more proven, well supported with success stories and case studies. More often than not, the key set of rules around the study has remained the same.

Looking at the history of scrum, Jeff Sutherland and Ken Schwaber conceived the Scrum process in the early 90’s. They codified Scrum in 1995 in order to present it at the Oopsla conference in Austin, Texas (US) and published the paper “SCRUM Software Development Process”. With the first publication of the Scrum Guide in 2010, and its incremental updates in 2011 and 2013, Jeff and Ken established the globally recognized body of knowledge of Scrum.

The scrum guide has gone through it own share of revisions. For the most part, the core to the revisions has been the need to keep the guide as simple as the scrum framework itself and to adapt specific terminology to make it more in line with how the industry has adapted the framework itself. The present version of the scrum guide is only 16 pages long with focus on the core framework.

I first got introduced to scrum back in 2007 when I spent 2 days with Jeff Sutherland, participating on a CSM class. Since then, I have been of the assumption that scrum has remained the same till very recently when I happened to attend another class while being in middle of projects. I was surprised to unearth some serious gaps in my understanding of scrum and when the current scrum guide says. I spent the next few days going through the guide multiple time to bring make my understanding of scrum current.

Additionally, talking to may coaches and scrum masters, I feel people have not felt the urge to go back and read the guide recently and have been teaching scrum to teams and individuals based on their past understanding and using the old terminology. This has impacted me so much so that one of the first questions I ask candidates in an interview is “when did you last read the scrum guide?”. This helps me assess how current is their understanding of the framework and the kind information I should be ready to digest.

While some might argue that the changes in the guide have been minimal, I believe the current guide is much simpler, gives a good understanding of scrum in least possible number of words and is definitely the best source to assess your understanding of scrum.

I can confidently say that just going through the guide will help you make the mental decision about the quality of your adoption of scrum without the need to go through the long and formal assessments.

So “have you read the scrum guide lately?” If not, I highly recommend you take a quick refresher and ensure you are doing scrum right. Click here to print the latest version.

 

It’s getting boring here…. how to keep scrum ceremonies interesting?

bored-cat_work-600x384

As I walked into the backlog refinement session for this team that I had been coaching for about a month, I felt a low in energy. Team members were busy doing their own “stuff”. While some were busy texting, others were on their laptops and since a backlog refinement meeting is typically linked to the Product Owner role, she was the one doing all the talking. It reminded me of the economics lecture in college where the professor was the only one talking while the class was busy thinking about the college annual festival.

Humans cannot survive any kind of repetitive event for too long. Scrum ceremonies are no exceptions. Sustaining interest in scrum ceremonies becomes difficult and they say “it is getting boring”. Their minds are always in search for the next exciting thing happening around them and the ceremonies are all about going through the motions without understanding the intent and outcome of the same.

Every scrum ceremony has a desired intent and outcome which is to be built on the core principle if team work driven by communication, conversations and collaboration. However, most Scrum teams lack the kind of chemistry to make these possible.

So what can one do to keep things interesting. Well, here are some pointers:

1. Location – As much as my kids love to eat at home watching their favorite TV show, every once in a while we go out for a meal. Change in surroundings  brings in interesting changes in people’s view point like sharing their dishes to get a sense of other’s taste, time for some family conversations and more.

So try to experiment with the locations for your ceremonies and observe the different it makes. An informal retrospective at a local restaurant or over a bowling session goes a long way in bringing in a positive change and  creative thinking.

2. Activities and games – Playing games with my kids is the best way to get some leanings across to them which otherwise is a big ask. As kids make their moves, I ask a question to help them select the best option. Other times they correct me if I  made a wrong choice.

Leverage games and activities to help create a collaborative environment between team members. tastycupcakes.org, innovationgames.com are some great resources for such creative and fun filled games. In fact there is a whole book written about how to conduct retrospectives. Check it out here.

3. Rotate – As much as I love to get a nicely cooked meal from my wife, I like to try my hands at cooking and trying new recipes from the internet or of my own. While the intent in doing so is to stick to have a plate of food that is healthy and also tastes good, a different approach to cooking can bring in unique flavor and taste.

So when it comes to facilitating a backlog refinement session or a sprint retrospective, allow other members of the team to get into the shoes of the Product Owner or the Scrum Master. Not only will this introduce them to the challenges associated with the role and ceremonies, it will also help to bring in some fresh ideas to the table on running the ceremonies and solving problems.

4. Reward – Rewarding the right behaviors and penalizing the wrong ones is something that everyone can relate to. This something that happens with is right from our childhood to when we grow up as adults.  Right or wrong, this has worked in majority cases.

When dealing with mature teams, this might not even apply, however; when starting with new teams and going with the “Shu-ha-ri” approach, following the rules becomes critical. Having followed the rules for a period of time, it becomes second nature. According to a research, for any action to become a habit, it takes an average of 30 days of focused effort. So while you would want to reward right behaviors, penalizing wrong ones will help sustain a balance. So discuss with your team to decide what rewards or penalties will work in your unique environment.

5. Don’t wait – I was never good at maths. I would avoid solving math problems as much as possible till the time my father would catch me just before the exams and make me solve a few. No marks for guessing that I would struggle. This would repeat each year and my father would tell me to share my challenges with him all through the year so he could work with me right then and address my issues.

Solving problems and raising issues as they occur is extremely important. If the team has to wait for the next ceremony to happen before they can bring up a problem, chances are they might forget it or not have a productive conversation given that the issue happened in the past.

Post Script – I wonder why scrum ceremonies would become monotonous and boring when the team has complete control of the “how”. Is it because the ceremonies do not achieve the desired objectives or because the team is still under some kind of control where they cannot exercise their decision making powers? It is quite obvious that these complaints sound exaggerated but these are common too.

So what is your view on this subject? What are some techniques you have tried with your teams? Leave a comment…

Distributed teams and dependencies – My talk at Austin City Limits Conference

I recently had this opportunity to talk at the Agile City Limits conference at the Dell headquarters in Round Round, Texas. There were a lot of awesome things about the conference. Awesome crowd, awesome energy and from the audience an awesome urge to ask some really great questions. Not to mention that the topic itself “Distributed Teams and Dependencies” was one that is the biggest concern with any large organization trying to adopt agile.

The primary intention behind this presentation was to decouple challenges with a distributed setup and agile. The problems teams and individuals face with a distributed team are resolvable through the use of right tools and techniques. With large and distributed teams, there is so much focus put on process that most teams gradually move away from individuals and iterations and drag themselves back to be driven by using more processes and tools.

The key to overcoming challenges with distributed teams is through using the right balance of agile teams with focus on product/project vision, cross team collaboration, building the right level of trust and understanding cultural sensitivity. Additionally, communication and collaboration tools along with required development tools become great facilitators for collaboration between teams. Teams using agile methods have had great success with tools like story mapping, backlog grooming, scrum of scrums.

I also took the opportunity to talk about what makes a good distributed setup and how organizations should focus on running Scrum successfully before scaling. At the end of the day, it is all about managing the distance.

The audience was particularly interested in understanding the opportunities around team dependencies. My focus in this part was to share my experience in how I and the teams I have coached addressed the challenges with team interlocks. After talking about why dependencies exist and the kind of problems dependencies bring, I walked through some tried and tested approaches which included:

  • Approach to plan to keep dependencies to minimum as you form new teams
  • Creating an open source model
  • Planning for dependencies ahead of time
  • Creating communities of practice for better collaboration

All in all, it was a great discussion and I hope the audience enjoyed attending my talk as much as I enjoyed presenting it.

Here’s my presentation.

Agile and software rewrite

Talk about software rewrite and one comes across varied opinions. With the advent of cutting edge engineering practices that facilitate opportunities to build things right the first time, many look at the need to rewrite software as a sin. When coming across developers and architects who want to rewrite software systems, you hear them saying things like the software is way too complex or the system was probably written by a dumb developer etc..

As you investigate the need for a rewrite, some of the more common reasons include:

  • System is not performant
  • System is too complex to understand
  • Technical debt
  • Unfamiliarity with domain and legacy code
  • Use of old technologies
  • Business feels the system is out dated
  • More..

So what is the right strategy for a rewrite?

Most business want to take a “like per like” approach, which means that the software be re-written to implement improvements without introducing any change from a customer experience view point since selling a change to a customer can be challenging. This mentality results in under estimating the complexity of the system and ignoring the opportunities for improvement.

A real world example that one can relate to is a new version of an existing car model that gets offered every couple of years. Would the car sell more if the company was to build a new version in the same exact way as the existing one? Well, not really. Customers look for improvements across the board, from improvement engine performance, latest features, more mileage and a refreshing look. So why should software be treated any different?

Is a complete rewrite acceptable?

The second is the most dangerous system that a man ever designs” Fred Brooks, 1975 & 1995

Complete rewrites will make sense if one can stop the world from changing but unfortunately that is not an option. So the first approach should be to refactor your way out of the problems. Most issues can be resolved by addressing the issues in a prioritized fashion. Systems when rewritten are mostly NOT written very differently from when they were written originally. There are still requirement gaps, architecture does not resolve all of the problems and teams still build a lot of technical debt.

Refactoring your way out turns out to be the most efficient both in terms of effort, cost and risk. Engineering practices like Test Driven Development (TDD), pairing through the issues and refactoring code can go a long way in making an existing system performant, allow teams to familiarize themselves with the domain and inside of the system and cut the effort of rebuilding features that never get used.

How can an Agile approach help?

Does Agile make sense for software rewrite? It absolutely does. Agile is all about continuous improvement and systems are rewritten to make them better in many ways including emerging improved architecture and value driven development. One huge benefit rewrites potentially provide is to get away from features not providing business value resulting in eliminating waste for development and maintenance activities.

In general, there is no reason to treat rewrites any different from a green field project. Agile approach if followed in a organized way should help building the right system maintaining a view of expected benefits. Lets assess one area at a time.

  • Requirements – Business and market situations change by the day. Rebuilding what you have today is not an option. Requirements should be captured and backlog created from scratch. While breaking requirements and creating stories, right amount of focus needs to be on the value each requirement offers. Systems with legacy code built over several years always carries a certain amount of risk. With churn in resources and changing business landscape, it is hard if not impossible to be aware of all legacy business rules. Hence, there is significant risk involved in assuming a complete familiarity of existing systems.
  • Small shippable increments and feedback loops – with focus on key improvements provide an opportunity to compare smaller increments with existing systems and adapt to missing pieces. This will also result in the need to understand only the part that is being recreated. Small shippable increments facilitate continuous feedback loops for faster validation and confirmation.
  • Speed to market – Continuous improvements in existing systems made in small shippable increments can be made available to customers frequently. This can go a long way in meeting customer satisfaction.
  • Customer collaboration – What better than engaging existing customers in making the product better. Most customers will be open to provide feedback about the system. Agile development principles encourage active ‘user’ involvement throughout the product’s development and a very cooperative collaborative approach. This provides excellent visibility for key stakeholders, both of the project’s progress and of the product itself, which in turn helps to ensure that expectations are effectively managed.
  • Team collaboration and knowledge building – Giving the team the space to understand existing system and propose what the new system should look like brings out the creativity to resolve business problem in more innovative ways and facilitates domain knowledge creation.
  • Engineering practices – are the key facilitators towards building software right the first time. Rebuilding is no different. These practices encourage refactoring to address issues with existing code and help in building quality with rewrites.

There are enough benefits to leverage agile principles and practices for software rewrite. Writing the software the way it exists today does not provide any benefits but results in significant waste and limits focus on improvements. I can say that Agile can be as effective for rewrite as it if for greenfield projects.

So, evaluate the opportunities through refactoring before you walk the road to rewrite from scratch. And if rewrite is the only choice, going with an Agile approach will provide the right tool towards building the next version.

Have you used Agile for a rewrite? If yes, do share your thoughts.

Coaching? You got to be kidding..

Looking back in time, last 6 years have been amazingly wonderful. During this time  I have seen my 2 kids grow and mature as I continue to grown with them. Time spent with the kids has always been the biggest stress buster. Whether it was watching them smile while taking those short naps to reading their first story or wanting all my attention as soon as I got home at the end of the day.

IMG_0326

As I think through how they have grown, I see a lot of similarities between bringing up kids and coaching teams. My parenting journey has helped me develop myself to fit into the coach role. With kids, coaching begins the moment a child starts to identify you as someone who they can trust and someone who is there to make their tomorrow better. Here are some key activities that I think have helped me enhance my coaching skills:

  • There was a time when they would just listen. They would just wait to get instructions and follow. It was up to me as a father to ensure that they were engaged and watching as I worked towards building a strong foundation.
  •  As they continued to grow, we celebrated every single achievement and guided them to overcome failures.
  • Come the age of 2 to 3, they started to explore. Explore ways of doing things differently without caring too much about the end result. I was happy to let them explore but made sure that they stayed within the boundaries and principles.
  • And there were those off days when they just refused to listen.  That was the time when punishing was not an option. I had to be patient, wait for them to settle down and then have a one on one discussion. The discussion was retrospective of what should or should not be done.
  • As I walk this wonderful journey of brining up my kids, as a parent I continue to provide constant feedback so that these basics principles of life are constantly reinforced.

My daughter Nehmat is now 6 years and she is one self sufficient kid. There are times when I need to get back to my coaching role as she continues to grow but I guess this is one assignment where I won’t mind being involved for the next few years.

My son Arjit is 3 and needs constant coaching. My coaching with him is in the “Storming” phase where there are more disagreements as we continue to work towards his next stage of maturity.

I am sure there are coaches out there without kids or who are not great fans of kids, this is just a glimpse of my life with my wonderful kids. They continue to challenge me each day with their thinking and that pushes me hard to continue learning and improving.