Category: Uncategorized

Seriously, why Agile? Home : Seriously, why Agile? We have been developing software for decades and we have witnessed more software projects fail than succeed. And, most software projects are considered as failed, either because a project does not meet a customer requirement or an agreed project timeline gets missed. We always run into a problem of too many features being promised to be delivered in an impossibly short period of time. We work with a customer, gather requirements and tend to think that we know what a customer wants and make a plan, project the release date and start development. Once we start developing we need more clarification and once we start working on clarification with the customer, as a result, we get more requirements. The customer assumes that additional requirements were part of what they communicated initially so they want all the features to be delivered in the originally agreed upon time. This makes no sense since scope is increased but timeline is not. However, the question is “Are all the requirements must-have for the release?”. As per the Standish group’s analysis, 20% of the software covers 80% of features used in a software product. The remaining 16% are used sometimes, 19% rarely used and 45% are never used. So here is the hidden treasure we need to dig into, how to identify that 20%  useful features or how to weed out the 45%  unused features so that we provide what customers need in the agreed upon schedule or even early.  I truly believe the Agile framework has many good reasons to be utilized, however one that bubbles to the top is that it helps us find that  20% of treasure that provides 80% functionality.   Let’s look at how we can follow Agile principles to identify 20% of the valuable features and save more than 50% of the effort; this means 2x the productivity or even more which is in line with Jeff Sutherland’s (co-founder of SCRUM) book “Twice the work with half the people”.   Agile Principle: “Simplicity–the art of maximizing the amount of work not done–is essential.”   As Steve Jobs said “People think focus means saying yes to the thing you’ve got to focus on. But that’s not what it means at all. It means saying no to the hundred other good ideas that there are.” Really we add 100s of features and ideas (either requested by customers or added by internal customers) to make a product cool! But it is not about making a cool product; it is about providing the right value to our customers. In many cases, we tend to add more and more features making the product more complex.  In other words, rather than making the product better it goes the other way around. So we really need to understand how to weed out the features that do not provide value or provide only low value.   The Product Owner Role is vital in the Agile framework(Scrum). The product owner is on the hot seat to prioritize the requirements based on the customers’ need, market competitiveness, company directions etc. The product owner should work with customers to understand the business need and why they need it and be able to articulate the business value. Just a simple few questions like asking customers why they need it – do they really need it, what happens if the requested feature is not provided, or what happens if the requested feature is delayed by 6 months etc. will weed out a lot of not needed features. This is the reason “Why” or the “So that” statement in the user story format is very strong and provides critical information that generally people underestimate. It really gives the purpose of the feature and gives way to prioritization plus getting you to think about the right solution. If the customer cannot explain why then probably that feature is not of high value or the customer may find it has already been included in an existing feature.   The product owner should prioritize the requirement along with customer and the priority should be forced ranked, meaning rank from 1 to n.  The requirement can be prioritized either based on value, the cost of delay or Weighted Shortest Job First (WSJF) etc. The value of software product is based on the benefit to their customers, such as an increase in productivity, an increase in revenue, an increase in customer/employee satisfaction etc. And the cost of delay is how much value the customer is going to lose if the feature delivery is delayed by x time period. WSJF is a well adopted method by Dean Leffingwell in the SAFe framework and is calculated with cost of delay and size of the work(for more detail visit  www.scaledagileframework.com/wsjf)   In many cases calculating an exact dollar amount for value and cost of delay takes a high amount of effort and in some cases it may not be possible at all. In those cases, I would suggest estimating relative value, as human beings are more adapted to size relative value better than an absolute value. And using the planning poker game similar to what we used in estimating user story size is the best way to bring more accuracy on value estimation. Similar to developers’ involvement in user story sizing, involve stakeholders (mostly customer facing individuals, at least more than 3 individuals) in estimating user story value and have them use Fibonacci numbers and vote the value. Please refer to the link below for Planning Poker technique for user story size estimation, please apply the same technique for estimation user story value https://www.mountaingoatsoftware.com/agile/planning-poker. The point of planning poker is getting input from multiple stakeholders in an unbiased manner and stimulating discussion if someone has a different opinion which will further clarify the requirement and its value. This is a very good technique to align stakeholders as per scope and value of the requirement as well. Once all the user stories are sorted by value then all… Continue reading Seriously, why Agile?

My ideal self organizing team and Me Home : My ideal self organizing team and Me I was talking to my colleague about painting a picture of an ideal self-organized team so that we can share with our teams. We had to appreciate that for many, this was their first experience with self-organization and that this was a whole new world for them. I was trying to find better way to express the characteristics of an ideal self-organizing team.  My first inclination was the trusty checklist of tried and true characteristics, but immediately thought better…why not a role play? Instead of words on a sheet, let’s make it come to life. So I decided to craft an email from a department director writing to her VP on how she feels about her successful self-organized team. The email and all the characters are fictitious :).   Hi Mike,   I wanted to drop a note about how happy I am working with my team. They are really amazing! It makes my day when I occasionally peek into their retrospective meeting through the glass door of the conference room and they are discussing, with full passion, how to improve their team performance and team happiness. I sometimes attend their daily meeting as a chicken and I get happy to see them being concerned about each other’s work and helping each other to remove impediments. They are highly respectful to each other and concerned about their sprint goal rather than just their individual goals. I think as they practice shared responsibility through the sprint they foster better teamwork.  And making the whole team accountable for the sprint outcome, has helped them to embrace team responsibility as well. I learned the hard way when I always asked David (Tech Lead) about the status. He suddenly changed course and started acting in a more command and control manner to the team; probably due to me pressuring him personally to get things done. Hence, I immediately adjusted my approach if they missed a sprint goal.  I realize now I should speak to whole team and not just to David. Through my observation I grew in admiration for David as conducted himself as an equal team member in the meetings. An excellent illustration of truly “being” Agile. It was clear that the after granting autonomy to the team,  they are highly committed to the sprint backlog items that they have accepted into the sprint. Empowering them to decide their sprint scope themselves was clearly the right direction. Initially I was skeptical if they would play it too safe and commit to less than what they could really do, but they really surprised me on how courageous they were by challenging themselves to be and they even started taking on more sprint after sprint.   The Product Owner Sally is highly dedicated as well, she attends scrum meetings every day and helps the team clarify doubt. In addition, she really tries out the new features of the application on a daily basis and provides valuable feedback to the team. Sally really protects the team when John (the sales guy) attempts to bother them about when his feature will be done. Of course I cannot talk enough about Brad the scrum master, he is super! He knows how to facilitate the meeting really well and always encourages the team to follow the scrum ceremonies. He is really on top of all the impediments the team has, clearing away hurdles so the flow of work is never interrupted. He also really keeps himself up to date on the latest practices in Agile and scrum and gets excited about sharing it with the team.   I just love these guys!  Even though some team members are in India, they always make it possible to have a good amount of overlap time. Sometimes the US folks stay late and India people come in early or the other way around. I know not having team members co-located is not ideal, however watching how they creatively solve for what works best for them has been amazing.   They really rock! They showed me their velocity chart and I really see it progressing sprint to sprint.  They even go out together often socially, of course the ones who are in same location. They have been asking me to get budget approved to get them together for a week in one location (either in US or in India), and well you know I have been asking you for a long time about that :).  Just the other day they showed me a list that they have created and they call it “Agile Team Health Checkup” that has items they want to improve as a team. Brad mentioned they review the list in every retro and see if they made any improvement in each sprint.   Oh, they are getting very active on inviting their stakeholders to their sprint review meetings and showing their demos as well. John (the sales guy) actually came to my office last week and told me how happy he is to actually sit in the review meeting and give his feedback. He mentioned he wants to get his customer at the retro some time soon. We definitely will find some good time to do that as well.  The product owner Sally told me she was so happy that team members are highly engaged in backlog refinement sessions; they ask very critical questions and help her refine the stories.   And to top that I found that they have printed their vision and working agreement and displayed it in each of their cubes. I asked about them and Sagar told me that the whole team worked together to craft the vision of their team. “Always strive to achieve the best and make the customer happy.”  I found it interesting that they have crafted a working agreement that says, “Be committed, be courageous, be honest, be open, help each other and more.” Want to hear something funny? They have a jar to deposit a dollar if anyone violates the working agreement. Well, I think its 50 rupees in India and a dollar in US. They are… Continue reading My ideal self organizing team and Me

The Real Agile Transformation Journey Home : The Real Agile Transformation Journey Agile has gone mainstream in large and small organizations. Organizations have started implementing agile not only in IT, but also in business divisions such as finance, marketing, HR, and more. There are many organizations trying to gain the promised benefit of Agile and every organization has chosen their journey of Agile transformation differently which has delivered mixed results. While Agile is really a simple concept to grasp, organizations often underestimate the hurdles to successful implementation. Many organizations expect a smooth Agile transformation journey as below. Get development manager or project manager certified as scrum master Form agile teams Create backlog Schedule and run scrum events Team will start delivering and will become highly productive Senior management and customer will be happy Organization will be agile  In reality – the path is a little more circuitous. Here is an example of a potential real Agile transformation journey: Initiate discussion about Agile transformation It can take months to determine what the next steps are, where to begin and whom to train to spearhead the transformation Finally send a few folks for training (typically Scrum Master training) After training try to form Agile teams Often important ongoing projects take priority over the new initiative, creating additional delays in the transformation Thinking resource optimization, the team is formed by speciality of work instead of a cross functional team or just converting existing project teams to Agile teams Team becomes highly dependent on each other almost like a waterfall – Data layer to middle layer and then to UI layer. Agile team keeps changing members based on project Manager take on the role of Product Owner and start writing stories but mostly as tasks Project manager takes on a role of Scrum Master and schedules scrum events. Project Manager(Scrum Master) actually assigns tasks to team and tells them how much they can do during sprint planning They have a lot of dependency on each other and the blame game starts to emerge All the parties involved are confused with new roles and no clarity People get frustrated and say why are we even doing agile Team does the work exactly the same way they used to do Leadership shows same command and control behavior Senior management question why Agile is not increasing productivity and reducing time to market Stakeholders get impatient They think agile is not working and either they go back to waterfall or they think this is agile and check off as Agile transformation being done The above scenario may be a bit extreme but not far from the truth. Agile transformation isn’t just about adopting new processes. It’s about transforming the way your team thinks and operates. A successful Agile transformation demands a holistic approach that takes into account all aspects of your organization’s structure, leadership, culture, and practices. Organizational Structure & Design: Do we have an organizational structure that encourages cross functional teams and fewer hierarchical layers. Does the team structure enables the smooth flow of work? Are appropriate Agile roles fulfilled? Agile Mindset & Culture: Are employees trained on the Agile mindset and are they embracing the agile mindset of early feedback, continuous improvement, experimentation etc.? Agile Practice & Tools: Is the correct practice framework selected and does everyone have the required training to be effective? Does the team have all the right Agile systems and tools that enables automation of their work? Leadership & Employee Engagement: Do the highest levels of leadership support and promote Agile transformation throughout the entire organization? Are they embracing servant leadership and fostering an experiment safe environment for the team? Since the organization’s structure, process, tools and culture are impacted, the scope of change is large for Agile transformation in an organization. Hence, attention to organizational change management aspects are key to the success of an Agile transformation. At the same time you want to facilitate change in an Agile way(iteratively and incrementally), instead of too much upfront planning and introduction of large change which creates resistance among employees. Some of the key aspects of facilitating changes are Creating an Agile transformation guiding team that includes Senior Management, Agile champions and coaches Building and communicating the vision for transformation Most importantly introduce small changes and experiment iteratively as below Build insights involving people that are impacted Create awareness, sense of urgency or desire for Agile transformation Build Agile knowledge and skills Experiment with the change iteratively Look for quick wins and communicate the success Transformation is always challenging, but by paying attention to the four pillars of organization and introducing the change incrementally with an experiment mindset greatly increases the success rate. Good luck to you in your Agile transformation Journey. As with anything else, the road to successful transformation can be navigated more easily with support and guidance from an experienced coach. While your Agile journey will be unique to your organization, Agile coaches can bring in their experience & expertise and apply their skills to make the process run more smoothly. At the same time coaches can help you develop your internal agile champions so that you get self sustained after reasonable time period. And Scrum Masters are key players of the success at the team level, especially in the absence of an Agile coach. At the very least, explore mentoring for Scrum Masters from an experienced Agile coach to get the best results. With a focus on more successful transformations, we work with organizations to unlock their true potential by transforming in a way that delivers results for customers, their employees and their shareholders. If you’re ready to see what an Agile transformation can do for your company, and how to execute a successful transformation, let’s get on a call. You can schedule call with us at https://calendly.com/agilemove/30min or email me at coaches@theagilemove.com.