Skip to content

Are You Practicing these Five Core Leadership Practices ?

In 2014, I had an interesting conversation over dinner with the CEO of a large office supply organization based out of United States. He had come on a 10-day trip to India to select an Indian offshore company to be his Agile provider for software development services.  My conversation with him took place at the end his trip. And he looked visibly agitated!

He had already met with many top software providers to learn about their ability to deliver high quality software and demonstrate Agile Software Development capabilities.   He was worried how the companies he met that week were saying “yes” to pretty much anything he was asking. He was concerned that they were not being transparent with him. He finally decided to set up his development center in Chile.

Stories like this or stories of customers unhappy with quality of software produced in India is not new. While there is no question about great software being produced by some brilliant development teams in India, majority of service providers are still being differentiated solely based on cost.

These companies typically have top-down and command and control approaches to running businesses. The culture prohibits openness and transparency over keeping customer satisfied. And leaders, bound by the years of practicing the above approaches in these organizations, often become the reason for Agile to not succeed.

While many leaders amongst us are going through transformation (as transformation of leadership has become the need of the hour), I wanted to share five core practices that are  essential for leaders to practice in such organizations in order to enable a change in their style of leadership.

1. Leaders removing impediments of the group they lead on a daily basis

Obstacle BoardThis is practiced daily by the leaders (directors) of a large video technology company in what is called as a management standup. Every day at 11 AM the leaders in this group stand around an obstacle board in Bangalore.The board is located in the teams’ floor so that everyone can know the movement in the board.

Obstacles are automatically moved up from Manager, to Engineering Manager to Director depending on a SLA of how many days stale the impediment is.  Each role of leadership is required to solve the impediments that are listed in their column.

They also maintain an online organizational impediment backlog in JIRA which is an Agile project management tool.

2. Keeping teams stable and empowering teams to make decisions

In Magarpatta IT park in Pune, there is a team called ScrumMatrix. Their management has decided to leave this team as is. Team members get to decide who joins the teams in case there is a vacancy. What’s the outcome, you ask?

This team builds embedded firmware products and they have a complex stack with multiple programming languages. They have been together for five plus year. Today they ship software weekly and all of them can now code in any layer of the product.

3. Removing waste in the organization

These are particularly the three kind of lean wastes – Overburden, Non-Value Add activities, and Uneven or Irregular work for the teams.

A Scrum Master of a healthcare company has worked to remove unwanted meetings and interruptions.

Today the teams in this group do not attend any meeting except the Scrum Meetings, and some design meetings. They all come to work at 9 and leave at 6. Their practice of core hours has removed the waste caused by unplanned work. The team is overall very happy as they practice “If it’s not in the backlog it does not exist

4. Ask More,Tell Less Policy

Instead of solving problems, leaders should ask the right questions that trigger proper behavior in teams.

I have learnt a lot from this leader of a world renowned consulting firm. He works in Gurgaon. As a Director, he does not have an office for himself and instead works with the teams in the team room. I have never seen him hold the center stage. He always has his other members talk or lead in any meeting. If you ask him a question, he would often answer in another question format.

He would always ask positive questions as he understands the 300 people who report to him will react to questions the way they would be asked! He practices Ask More, Tell Less Policy.

5. Trusting teams and letting them directly work with customers.

Our Director friend is a great example of this fifth practice.  All teams in his leadership are encouraged to directly work with global customers.

He has created a place where people are able to speak up openly as well as help each other. They feel safe that their boss will not get upset at them as he is always there to help them think through the problems.  

This ends my thoughts on leadership practices that each one of us could try to adopt and make our transformation true, and change some perceptions too.

Explore more about the constant battle software teams face between Quality and Speed, along with case studies of customers that value Zero Defect Software Development by attending SolutionsIQ’s Leadership Meet in Bangalore India on May 18th at the Hyatt in Bangalore.

 

TRUST – the unspoken element of Being Agile

Having worked with varied team(s) with different personalities, one of the realization for me is that “TRUST” plays a key role in team bonding and getting to a high performing stage. While there are many factors that reach teams to the stage of high performance, I have put here my interpretation of trust which I believe is vital for building a great team.

Trust can be viewed from three different dimensions as mentioned below.

  • Trust between the team members on each other
  • Trust on the team by the management
  • Trust on the management by the team

pic2

Let us recall the difference between a team and a working group. A team is a group of people working towards a shared common goal where as a group is a collection of people who coordinate their individual efforts.

The Trust Blockers and Enablers

Generally when an Agile team, specifically a Scrum team is formed, the behavior of the team members trying to showcase their individual work and hesitating from sharing knowledge with the rest of the team is observed in few instances. This behavior can be attributed to the way of working the teams are accustomed to from many years, and any sudden change would for sure call for a resistance. Scrum Masters and Managers, when they notice such symptoms, need to talk to the team members, take them into confidence, understand what was motivating them before and what is not after the change. They need to empathize and be approachable to the team and do one-to-one coaching to understand the root cause for this behavior.  They need to coach them to help them realize that they are all in the game together and they win and lose as a team! The norm seen in some of the agile teams is that even though teams are formed with members from different functions like testing, development etc. the team members still report to their functional managers. In such situations, the functional managers should understand how a cross-functional agile team works and guide them, and restrain from giving preference to their individual functions. If the ecosystem is not supportive and encouraging, then any great process and practices put in place would not yield the expected results.

Similarly, the team needs to appreciate the new way of working. They need to be true to themselves first and then to their team members and then to the management.  Team needs to get the concept of self-organizing and should be ready to take up the work, forecast what is achievable by them and step up to take ownership for their commitments.

Any one dimension of trust not being present effects the whole ecosystem and brings the motivation down. The importance of trust is evident even from the statistics, the Version One Annual State of Agile™ Report states that – lack of management support, unwillingness of the team to follow agile, development team support etc. are some of barriers to Agile adoption. If we reflect on these barriers, some of them could be related to people issues and trust factor could play an important role here.

When team members and management trust each other, automatically the team members go an extra mile and work outside their boundaries without being asked for. Trust leads to motivation of the team, and they strive to give their best that eventually makes them committed. Think of these traits as a vicious circle where each one of them impacts and leads to the next one. May be we can visualize trust as a super planet driving all other behavioral planets.

pic3.

There is always a factor of egoism that often pops up and not all team members like to work with each other. They would want to be in their own comfort zones for whatever reasons. Building trust within the team takes its own natural course, I would say it is a journey and it takes time to get there! There is no one right answer of how to build trust quickly, to some extent it depends on the attitude of the people involved.

Trust can be perceived as the foundation for the 5 Scrum values –    Openness, Courage, Respect, Commitment and Focus. I feel if the team members basically trust each other and the management, then they would be courageous to commit and be open to voice their opinions, willing to share their work and respect each other, willing to focus together on the team goal and all these ultimately would lead to commitment.

pic4

Having said that, keeping the foundation strong is not an easy job, everyone has to be together in the game!

Signs and Implications of Mistrust

Here are some statements that could be an indication for the foundation getting weak,

  1. I don’t know about what is happening in the sprint.
  2. I am not able to collaborate.
  3. I don’t understand why I am being questioned for my work.
  4. I have sent an email, I am waiting for a response (thought the person sits next to you)
  5. Why do you need 10 hrs? If I were you I can do in one hour.
  6. Why is the velocity not increasing, I expect a trajectory in the velocity.
  7. I have worked extra in last sprint, so I will compensate by working less in this sprint
  8. We are an agile team, no one can question us on what we want to do
  9. Comeback to us only on last day.
  10. I am working on many other organizational initiates not being shown as sprint work, where is that effort getting tracked?
  11. Why am I not being recognized for my extra mile?
  12. I need documentation evidence for every discussion.

Here are some of the implications of lack of trust from the three dimensions

  1.  Within the team- Team members questioning each other on time spent and not convinced with each other’s arguments, hiding work and not willing to share work and help each other. Team members stepping into other’s shoes, trying to showcase their own superior work.
  2. Management on the Team –   Management asking for reports, proofs and questioning the team on every hour spent due to the lack of visibility into what has been done.
  3. Team on the Management– Team plays with hours and estimates, team does not step up when there is a need.

Tipping Point

pic5

All of us know the Tuckman ladder stages that the teams go through, i.e. Forming, Storming, Norming and Performing.  If at some point, that can be viewed as the tipping point, say the team isn’t really getting together for whatever reason, may be it is worth to dismantle the team and try with a new combination. Seed them in different teams where the ecosystem and the environment is new.  It is like when you make new friends and experience new things, the perspective changes and things might become better. This is just a thought and might not work for every team and may not be the right decision.

When peeked into the Agile Principles, I felt some of them implicitly highlight the importance of trust in some form or the other. Here is how:

  • Business people and developers must work together daily throughout the project: Helps build TRUST between the team and the business.
  • Build projects around motivated individuals. Give them the environment and support they need, trust them to get the job done: The need of TRUST is explicitly highlighted here.
  • The most efficient and effective method of conveying information to and within a development team is face-to-face conversation: Face to face conversation leads to developing the TRUST.
  • At regular intervals, the team reflects on how to become more effective, then tunes and adjusts
    its behavior accordingly: Regular reflections and open discussions helps build TRUST among the team.
  • Working software is the primary measure of progress: Helps gain the TRUST from the customers as they get to see what is happening on their product and are notified of any bottlenecks as they come up.

My parting message: Behind every great team building great software, there is trust. One has to work hard at times to build it, but it is totally worth it.

Agile , DevOps , Continuous Delivery – Defined!

If you are leading or working for an organization that does anything with software you probably are hearing a lot of buzz around the words Agile, Continuous Delivery, and DevOps, Agile Transformation or DevOps Transformation!

This article is a simple description of what Agile ,DevOps, CD are. The reason for this article is to clear the simple doubts on the terminology and see how they are related to each other. This article is not to challenge anyone’s believe on what these words mean. This is just a view of how many of us at SolutionsIQ perceive it.

Agile is a mindset that embodies the beliefs of people, systems and organizations. It is also really important to note that there is a huge difference from doing Scrum or Kanban from actually being Agile.

Continuous Delivery is a technique that enables organizations to ship the product as soon as it gets done. This gives the ability to the product owner or product manager to decide to release whenever they want.

A subtle difference between continuous delivery and continuous deployment is Continuous Delivery does not imply going to production but continuous deployment does.

DevOps is a wave that followed the agile and continuous delivery wave.

Dev Ops is a way to enable organizations deliver business value faster and continuously by fostering collaboration between Development and Operations.

Ok now that some of the basic descriptions are out of the way. lets consider some comparisons between them.

Do you need to be Agile to enable Continuous Delivery – Yes

Do you need DevOps to enable Continuous Delivery – No

Most organizations that say they want DevOps today are really not prepared fully to do it. It helps to create the Agile culture across the organization before embarking on the DevOps Journey.

So in order to enable to DevOps in an organization you have to think about the entire value stream.


Picture3

Picture2


Most organizations have two sides. Business and IT. Even after the software industry being present for 40 plus years, the model shown above which comes from the industrial era is still prevalent.

When people talk about Agile or Continuous Delivery, so far that has been mostly on the IT side. Some parts of the business like the product managers do get involved in the role of product owners if you do Scrum but that is it. All the other functions are still done the old way.

Funding – Still most companies practice annual funding models.

Sales – Contracts are still being written in a waterfall fashion.

Marketing – Till date it’s not aligned closely with day to day activities of the company.

So if DevOps is enabling organizations to delivery value faster the entire value stream needs to be streamlined.

Across the industry the maximum delay actually happens neither in IT or Ops, it happens on the business side. By the time the requirement actually becomes a valid backlog item, the organization has already lost 50 – 60 percent of the time that it takes to deliver value.

That is why the three things are important for DevOps

  • Agile and or Lean Principles – Business / IT
  • Effective Engineering Practices – IT
  • Value Stream Automation – Business / IT.

Most important in DevOps is not just a tool change. You cannot just get tools like Docker, Chef in place and call it done.

If you are interested is more learning register yourself for a series of webinars hosted by technology  Consultants from SolutionsIQ.


“DevOps: Unfolding the Mystery”. The first episode of the series is happening on Friday, 18th of March, 2016.


The webinar is going to share about the concepts of DevOps and will help in getting answers to questions such as:

Is DevOps just a new buzzword or was it was already there?

Is DevOps about automation and using the Cloud?

Who needs DevOps?

This is highly recommended for anyone looking for clarity and anyone who is not 100% thrilled about his/her information on DevOps.

Sign Up Free here

For more information on

Note: This article reflects the views of the author alone.

When to embrace Behaviour Driven Development?

Abstract

Behaviour Driven Development (BDD) is a collaborative and disciplined technique to help us build the right product. In the last decade BDD has had her own bit of glory and criticism. Many teams in the recent past have reaped benefits from this technical practice, while some teams complain that are yet to find any value. This article focuses on answering two questions; Why BDD might not always be the right choice? What are the ideal conditions when teams should adopt it?

Introduction

Behaviour driven development [1] has been a buzz word in the recent years and many teams are adopting it. The core of BDD is the collaboration angle that enables teams to build the right product. As a side effect BDD gives you a very essential output, which is an automated acceptance test suite. BDD team members work together in identifying different scenarios elaborated in the form of examples. High performing teams ensure through working agreements to only pull those features in which scenarios are well defined. These scenarios define the acceptance criteria of the feature. The scenario identification process involves full team participation and in these meeting its essential that the three amigos i.e. the entire development team, QA engineers and product owner should participate.  Along with the three amigos any other members who can constructively contribute in scenario identification are also welcomed.

During these interactions technology facing members get a better understanding of business and vice-versa. It has also been observed that identifying and discussing scenarios helps the team in analysing and studying the feature in much detail. Many teams benefit from this practice as it helps them shape their product ,  saying so few teams are yet to find value in investing time and effort towards these meetings and ceremonies . One should keep in mind that for BDD to be effective we require full team participation.

In this article I am making an assumption that these teams who are not finding much value in adopting BDD, were practicing it in fullest of its spirits and not just documenting scenarios for creating an automated test suite. This article doesn’t discuss on how to effectively practice BDD, as it’s out of scope. This article will throw some light on why BDD might not always be the best fit for all type of product development.

Problem Space and Solution Space

Before we go further I want to share a high-level concept of problem space and solution space [2]. I have been studying this concept for few years and have always loved to co-relate BDD with this concept for better understanding.

Any product that we build exists in solution space whether it is mock-ups, wireframes, prototypes or the actual product. Typically Engineers, Developers, Quality Assurance, Operations etc. loves to reside in this space and their thinking is skewed towards the solution. Whereas problem space is more abstract, vague or could just be a thought or idea like, “How to help farmers”. This is the space where the customer’s wants, needs, pain points reside. It is also home for our Product owner. If we identify the right problem space and marry it with the ideal solutions space, we have a blockbuster product.

The Gap

pic1

The above figure depicts the problem space and solution space in typical software development teams. The problem and solutions space are disjoined and there is a gap between the mind-sets of people who live in product and solutions spaces. For example as developers we are more comfortable to think about the code that will realize the requirement than the requirement itself. Hence as developers our thought process is more skewed towards solution space. Similarly a product designer or product owner might not be aware about the technical complexity of a particular requirement that might look simple and innocent.       

Complexity

Since we got a feel of these two spaces we should also know that each of these spaces has its own complexity. For example if we want to build a simple shopping cart application and we approach a team whose expertise was building e-commerce applications, building this product  might  be simple for them. In the above example both the problem and solution space complexity was less. Complexity is very much related to the team’s area of expertise and the product that they are developing, hence its very context dependent. For example if we give the same task of developing a simple shopping cart application to a team who is only  developed  embedded software , the product development could be a bit challenging for them . An example for problem space being simple and solution space been complex could be developing a product that automatically identifies objects (e.g. car, phone, monkey, money) in an image. Similarly teams developing a MRI clinical application suite for radiologist might find both the solution and problem spaces complicated because understanding the problem might require understanding medical terminology, how radiologist works with these applications etc. The solutions space is also complex meaning that the team might need to invent novel concepts to analyse and visualize the data.

Based on the above discussion we can classify different product developments into four categories (check below figure) based on the complexity of problem and solution space.pic2

In our above discussions we always considered complexity as an attribute associated to the entire product but the fact is that each story or requirement has its own problem space and solution space complexity. When we say that the problem space of a product is complex we assume most of the requirements are complex in problem space. In most of the cases one would get a big picture about the complexity levels of the product by analysing the stories that make up the minimum viable product[3].

When to use Behaviour Driven Development

BDD works pretty well when the problem space is complex. This is because BDD’s disciplined approach enables collaboration with the stake holders residing in either of the spaces which help in reducing this gap which we discussed above. Teams who had adopted BDD  often comes with flying colours if  their problem space was complex and solution space was simple , this is because during the scenario refinement process the developers get to know what exactly the need to build and they know how to build it the right way. In case when both are complex BDD helps in narrowing the gap, enables shared understanding [4] which in turn makes the life of people in the solution space much easier and they can start the other half of getting to the solution right. In such situations when both the spaces are complex BDD will only help in defining the problem. The success of the product also depend how engineering teams come up with the right solution. Kindly note “BDD doesn’t come with brains, we have to use ours”.

Below is the BDD adoption matrix. We can see that when problem space complexity is high we tend to get more benefit from adopting this practice. This doesn’t mean that there is no benefit at all in adopting BDD when problem space is simple. In all the below four cases we get the benefit of getting an automated test suite of acceptances test, but that is just the side effect of BDD. Teams whose problem space is simple can continue to document scenarios and automate acceptance testing but they need not spend elaborate time and effort towards discussing and debating scenarios. Either the developer, tester or product owner could come up with scenarios; team reviews it and start developing it without spending too much time discussing it. The problem space being simple it is expected that everyone understands the problem pretty well and there is less scope for confusions and doubts.

pic3
One thing to be noted is that just documenting few scenarios and automating it as test is not BDD.  If you don’t spend quality time to have the right conversations between the people of either spaces and capture these scenarios as examples BDD is not complete. This means that you need full team participation in these discussions and to make the best of  Return on Investment (ROI) spend on time and effort, it only makes sense if problem space is complex. This is why BDD can be an overkill when the problem space is simple and this is the reason why some teams complain that are yet to find any real value in adopting it.

How to Measure Complexity

How can you measure problem space complexity?  Answer is, it’s difficult. There could be cases where the problem looks simple due to second order of ignorance [5]. We say second order of ignorance exist if “when I don’t know that I don’t know something”.  As teams who are starting to practice the BDD style of working, inspect and adapt would be the right way ahead in understanding and taming the complexity beast i.e.  Teams will have to make mistakes and learn from them. Another approximate and still effective way of estimating complexity is to use the 5 point scale which was proposed by Liz Keogh in her blog Estimating Complexity [6].  With respect to the below table one can reap greater benefits and better ROI embracing BDD if your problem complexity is greater than 2.

Points Complexity Description
1 Just about everyone in the world has done this
2 Lots of people have done this, including someone on our team.
3 Someone in our company has done this, or we have access to expertise
4 Someone in the world did this, but not in our organization (and probably at a competitor)
5 Nobody in the world has ever done this before

Conclusion

For a successful product development it is crucial to bridge the gap between the problem space and solution space. The problem space and solution space has its own set of complexities which is context dependent. Behaviour Driven Development can be one of the effective techniques to bridge this gap especially if the problem space is complex. In case the problem space is simple it might be an over kill and teams might not find real value practicing BDD.

I hope this article has cleared some mist on when your team need to embrace BDD. Please let me know your thoughts and feedback.

 

Bibliography

[1]  North, Dan. “INTRODUCING BDD.” Web log post. Http://dannorth.net/introducing-bdd/. Dan North Associates, 1 Mar. 2006. Web. 19 Jan. 2016.

[2]  Olsen, Dan. The Lean Product Playbook: How to Innovate with Minimum Viable Products and Rapid Customer Feedback. John Wiley & Sons, 2015.

[3] Robinson, Frank. “Minimum Viable Product.” A Proven Methodology to Maximize Return on Risk. SyncDev, n.d. Web. 19 Jan. 2016.

[4] Evans, Eric. Domain-driven design: tackling complexity in the heart of software. Addison-Wesley Professional, 2004.

[5] Armour, Phillip G. “The five orders of ignorance.” Communications of the ACM 43.10 (2000): 17-20.

[6] Keogh,Liz. “Estimating Complexity.” Web log post. http://lizkeogh.com/2013/07/21/estimating-complexity/,  21 July. 2013. Web. 19 Jan. 2016.

Top 15 changes you should know about the latest Scaled Agile Framework (SAFe 4.0)

The Scaled Agile Framework®, or SAFe®, provides a recipe for adopting Agile at enterprise scale. It is illustrated in the big picture. As Scrum is to the Agile team, SAFe is to the Agile enterprise. SAFe tackles the tough issues – architecture, integration, funding, governance and roles at scale.  It is field-tested and enterprise-friendly.

The version SAFe 4.0 features extensive refinements to many elements of the framework, as well as new content and guidance that helps enterprises better organize around value delivery, develop systems that include hardware and software, and improve development, coordination and implementation of large value streams.

Here are the top 15 changes that you should know about the new SAFe 4.0:

  1. The new SAFe 4.0 now supports both software and systems development
  2. The Big Picture can be expanded to three or four levels, default view being the three level version (Three-level SAFe) made simpler than its predecessor and with one click, expand to Four-Level SAFe to handle the needs of large value-streams and most complex systems development.
  3. 3-Level SAFe is for smaller value streams of around 100 people or less. It includes Team, Program and Portfolio levels
  4. 4-Level SAFe is for large solutions including 100 or more practitioners per value stream and there exists several of such value streams in an organization. It includes Team, Program, Portfolio and new Value stream level.
  5. A new Value-Stream Level is introduced with new roles, artifacts and activities, to cater to the needs of those who are building world’s largest systems.
  6. Enterprise Kanban Systems manage the flow of work across all levels
  7. The SAFe Requirements Model has been updated to reflect additional backlog items and to handle the new level introduced in 4-level SAFe.
  8. A new Foundations Layer envisions the values and principles that drive the overall framework and program execution             
  9. A new Spanning Palette carries roles and artifacts applicable across levels with increasing modularity and customizability. One can now pick and choose items from this palette at any level based on the context.                                                                       
  10. Built-in Quality Practices now supports both software and systems development
  11. Foundation: The new version provides guidance for Lean-Agile leaders, Communities of Practice (CoP), Core values, Lean-Agile Mindset, SAFe principles and proven implementation patterns. Core values such as Alignment, Built-in Quality, Transparency and Program Execution continue to guide the overall framework.

safe4.0bigpicture312. Portfolio:

  • The enhanced Portfolio level provides improved guidance for enterprise-to-portfolio strategy formulation and portfolio communication, organizing and funding value streams, managing the flow of larger initiatives, governance and cross-value stream coordination.
  • Organizing around value via a portfolio focus on the Value Streams
  • Enhanced Lean-Agile Budgeting for funding the Value Streams, rather than ARTs (Agile Release Trains) with a view on CapEx and OpEx.
  • One Portfolio Kanban system for both business and Enabler Epics
  • Improved guidance for Value-stream Co-ordination within a portfolio.
  • Terminology Changes: Enabler Epics (previously architectural epics), spans across all levels of SAFe. 

13. Value Stream for those building the world’s largest software and systems that includes guidance for Solution Intent, Solution Management, Engineering and Architecture, Customer and Supplier relationships and Value-stream Co-ordination.

  • New Backlog item Type: Capability
  • New Roles: Customer, Solution Architect/Engineer, Solution Manager and Value-Stream Engineer
  • Guidance for working with Suppliers
  • Value-stream cadence and Synchronization across trains
  • Managing fixed and variable Solution Intent with Model-Based Systems Engineering (MBSE), Set-based Design and Agile Architecture

14. The enhanced Program level describes Agile Release Trains, teams of Agile teams that build Solution Capabilities and sub-systems. ARTs align teams to a common mission, provide architectural and User Experience governance, facilitate flow and provide objective evidence of progress and fitness for purpose.

  • System Architect role now includes engineering for systems development.
  • New Milestones provide an objective way to plan, manage and measure progress
  • Terminology Changes:

                i.   Release Any time (was Release on Demand)

                ii.  PI Planning (was Release Planning)

                iii. PI System Demo (was PI demo)

                iv. Enabler Features (was Architectural features)

15. Team level: SAFe teams are self-organizing, self-managing and cross-functional. With SAFe 4.0, teams have a choice of methods to apply Scrum and/or Kanban, with XP practices, as long as they are able to deliver valuable, tested and working software and systems every two weeks.

  • Scrum Master and Product Owner to participate in Scrum of Scrums (SoS), PO Sync or combined ART Sync
  • Agile Architecture has moved to the value stream level
  • Key Terminology Changes:

               i. Iterations (was Sprints)

               ii. Enabler Stories (was Architectural Stories)

               iii. Built-in Quality (was Code Quality)

               iv. Agile Teams (was Developers / testers)

 

Reference: www.scaledagileframework.com/whats-new-in-safe-40 

Manager’s Guide to Effective Release Management

It is not an exaggeration to say that agile has become the default way of working and organizations are seeing great benefits by making it part of their development culture. While there are many advantages seen in adopting agile, we do see many challenges while practicing in reality. To set the context for this article let us consider organizations that work in complex environments with a legacy of products and hundreds of teams involved. Release management and planning the next product release has been a well acknowledged challenge particularly in market driven product development.

Release Planning

Release Planning is the process of planning the next release of the product, it helps Product Management to predict, forecast and make realistic commitments to the stakeholders. A consistent release planning process enables organizations plan how much of business value can be delivered within the available capacity. Predictability plays a very vital role in enabling organizations to live up to the expectations of the customers, helps them gain trust and develop long term relationships.

Every release will have a set of “Mandatory Requirements –MR” i.e the Must Have features, that have to be completed before doing a release. The key parameters that influence the release plan are the business value drivers, schedule and budget constraints, available capacity, technical feasibility of proposed implementations,  previous release metrics, inputs from business development group who work very closely with the target customer segment, etc

pic1

The release backlog is usually categorized into different buckets like New Features, Technical Debt, Production Support and infrastructure for the ease of managing.  Organizations have their own guidelines for defining the size of these buckets and in general depend on duration of the release, team capacity and prior release metrics. Another important factor that might influence the type and size of these bucket is the long term strategy and goal of the Organization and “UX  research” can be one such bucket.

Release Management

Release management is managing the release to ensure it is on track. As part of execution of planned items in the release, the release plan that was envisaged in the beginning can change depending on various inputs from customers, internal stakeholders, market conditions etc. and the same is reflected in the mandatory requirements. Once the release is planned, having periodic health check points for assessing the health and progress is indeed very vital for a successful release. The Product Owners can use some checklist of metrics against which they evaluate if the individual teams are “Ready for release”. This list can have points like how many items are done, items scheduled for upcoming iterations, items completed but yet to be verified, high Priority regression items-open and closed, defects from new functionality etc.

pic2

Release Health Checks

The Product Owners regularly meet to check the Release Health based on how the teams are progressing, and take necessary actions to adjust the backlog across the teams if needed.  They can take a call to re-prioritize and make changes to the individual team backlogs so that overall Release Mandatory requirements are met. Reports are generated periodically based on the release checklist that give information of the team’s current state with respect to these checklist items. These reports show whether the teams are doing good, or behind schedule or ahead of schedule, they give an indication of how the release progress is happening. These reports are analysed to review items completed and yet to be done, individual team velocities and accordingly the teams marked as Red, Yellow or Green. Thus the product management will be able to assess the overall Release Heath at the release backlog level by doing such periodic release health reviews/checks.

pic3

In spite of planning a release considering all the above factors and trying to manage it by doing periodic health checks, there are instances of not being able to meet the release commitments. Organizations are forced to either cut down on the scope or extend the timelines and end up in running into the same problems as we have seen traditionally, trying to fire fight the last few iterations just before the release to meet the release commitments particularly when the release cycle is more than 1 year due to the inherent dependencies as involvement of many teams.

Release Mangement: Best Practices

Based on my experience, here are some of the good release management practices that have yielded reasonably good results to the satisfaction of the customers with good quality.

Smaller Chunks

I have seen that release planning is found to be very effective when the entire release is split into smaller chunks as it gives a better leverage for focussing and managing the backlogs. This also eases the dependency management across teams as the focal point is now reduced drastically from a year to a quarter or even much lesser timescale that depends on the organization. The feedback cycle for the release is also reduced enabling to inspect and adapt at a faster rate. Planning in short horizon helps reducing the unknowns at a much faster rate.

Product Owners in Sync

Very high level of coordination is required among the Product Owners for the release management to happen effectively. Unless there is good coherence and synchronization between the Product Owners the release management will not be smooth particularly in organizations with complex and interdependent projects.

Spike Sprint

We have also seen many unknowns coming up especially in complex product development environment, and in such cases the Product management group could execute a spike sprint involving few subject matter experts to understand the complexity and feasibility of the upcoming release. In such situations enough bandwidth has to be reserved for such spikes.

Release management is pretty tough and needs to be planned well, especially in organizations that have a legacy of complex products. However by carefully monitoring and adopting some good release management techniques organizations can overcome this hurdle. I have seen organisations doing releases successfully within time and with good quality by early identification and resolution of issues. And finally I would like to conclude by saying that the benefits for sure outweigh the challenges if release is planned, managed and executed well.

Why Sprint Planning Fails?

Sprint planning is the first ceremony teams do during the sprint. It is intended to set the context for the sprint, that, with the team at the center.

So, here’s what happens during a sprint planning –

Sprint Planning Begins——————————————————————————-

  • The product owners presents his/her wish list to the team
  • The team looks through the items on the list, has a conversation with the product owner, on items that need clarification.
  • The team, based on empirical information, picks up items that they think will be able to finish within the sprint

———————————————————————————-Sprint Planning Ends

Simple, isn’t it?

Well, not really

Get into one the sprint planning meetings for a team that’s new to Scrum, and you will realize how simple, “Simple” really is.

For teams that are beginning to Sprint, Planning meetings can be a bit of a challenge, especially teams that are used to do longer delivery cadences, “High Level Design” document, “Low Level Design” document, Risk and Mitigation Plan documents, and what not.

It’s likely that, during the first few sprints, teams might find it difficult to derive value out of the Sprint Planning meeting. Its natural and acceptable, if such teams overcommit or under commit for the first couple of sprints. (Of course, the focus is to Inspect and Adapt effectively, not have a perfect planning meeting, which might not serve the product goal) The team needs to gets into the pulse of understanding how much of work the team can accomplish within a sprint. Until that happens, the onus lies on the Scrum Master to facilitate the ceremony effectively, and guide the team efficiently

What I am going to talk about today, are a few patterns that may lead to an in-effective sprint planning meeting. These are patterns “to-watch-out- for” for Scrum Masters.

 

  1. Product owner or Manager driving the outcome of Sprint Planning Meeting

Teams that are purely business driven often face this challenge. We see the team members walking into the team room for the Sprint pic3planning meeting, and the meeting starts with the Product owner or the Manager saying “These are the stories that we need to get done by the end of the Sprint”. Thuddddd!!! The list then gets slapped on to the team, and the team is left wondering what to do. How do you think it feels being on one such team? Well, I wouldn’t blame the Product owner. He/she is purely driven by business.

As a Scrum Master, what can you do here? Well, educate the product owner. As a team, it’s only so much you can do. Anything beyond the team’s capability would be costly on the quality. Imagine owning a product that’s “On-Time” but not “On-Quality”

 

  1. Improper Slicing of stories during Planning Meeting

I could not stress more on the need to have all stories split rightly. By that I mean, a vertical slicing of the user story, not a Horizontal pic2Slice. Close your eyes and imagine your favorite pastry, with multiple layers of cake and cream. Do you see yourself eating it? You always take a bite through all the layers, corrects. That’s when it feels like heaven. You would not imagine eating the creamy layer first, then, moving on to the cake.

Well, why not do the same thing during the sprint planning. When attempting to break down user stories, it’s necessary to break it down into vertical slices – pieces that cut through all the tiers of the application. If teams do not make a conscious effort of this, the team will end up creating separate tasks for UI development, writing the services, for validating the code etc. The only solution is to make a conscious effort towards rightly splitting the story.

 

  1. Unclear commitment

Teams sometimes come out of the Sprint planning meeting, without having made a commitment to the items that get into the Sprint pic1Backlog. A Sprint Backlog is the list of Items that the team is confident about finishing by the end of the sprint. Without this conscious commitment, the team loses its drive during sprint execution. The product owner is not aware of what the team intends to complete by the end of the sprint. It’s easy to work through this. Having a Sprint Goal for every sprint, brings in the element of commitment within the team as well as the business stakeholders. Having a Sprint Goal or a Sprint theme, also helps teams to prioritize items within a Sprint Backlog.

For those of us who are in love with cricket, we are aware of the Duckworth–Lewis method. This method takes into account the fact that, the team batting second already has a target of a goal to reach. Having a goal, always helps things put back on track.

 

  1. Over-Analysis during Sprint Planning

Teams, sometimes, get into a mode of Analysis Paralysis. It’s easy for teams to get carried away, and start to rip open the code, look at code possibilities, even try out a small Spike, all during the sprint planning meeting itself. Ok… So, why will it be a problem? Well, not only does it lead to a situation where no outcome is achieved, it drains people out. A discussion with no outcome tires the mind. This can happen partly because, the story that was brought for discussion was not clear yet.

What can the Scrum Master do in such a situation – Simply, point to the clock. The sprint planning meeting is time boxed for a reason.

Stories that lead to team asking one question after another, probably needs grooming.

These are some of the most common anti patterns that I came across during my experience. Feel free to share yours.

An Insight to Agile Estimation Techniques

Software Estimation is an art, requires lot of system thinking, knowledge and courage. Estimation is done to know the likely cost of a project. It’s also helpful in defining the release date for new features.

In Agile environments there are two main estimation techniques: Fibonacci and Hours.

Fibonacci is an estimation technique that uses attributes. Fibonacci is associated with story point, used to estimate larger pieces of work (i.e., User Stories and Epics). It’s worth mentioning that Agile teams estimate tasks only in hours. Tasks are parts of a User Story, something very small that should take a couple of hours or so—definitely no longer than a day to complete. The larger the task, the lower the chance of estimating the exact number of hours associated with delivery.

The most common method used by Agile teams to estimate is Planning Poker.

In Planning Poker the story is narrated by product owner to the team. When team members show their estimation cards, we can see a variation in the estimation. The whole idea of involving team in the estimation is to have a shared understanding of the requirement with potential risks identified at the earlier stage. We must keep in mind that variance in the estimation play a very important role, it’s also an indication that all the members are actively involved.

For common understanding I categorize the estimates in three categories:

Optimistic Estimate – The estimates which are on lower side, suggests that work is relatively simpler and team is confident.

Average Estimate – These are generally not too high or low.

Pessimist Estimate – Estimates which are on higher side, indicates the risk involved.

When team is new, you may see more variance in the estimates. This helps all members to have a quick justification on their estimates and sets a platform to have a shared understanding across the team. Once the team runs through the calibrate sprints, the estimation variance is reduced, in case the estimation variation still continues to be high, possibly there is a smell.

  • Team doesn’t have a common understanding of the product
  • Backlog refinement is done only with ‘key’ team members
  • Is team focusing only on the effort or complexity to derive the story point
  • This is also an input to identify where the team members are required to be trained to increase their confidence level
  • Pessimist estimates indicates that there is more risk in implementing the story, team must clarify this and help the team to mitigate the risk
  • Also indicates if the user story or epic is too large to conceive
  • Is there any conflict of interest

Agile teams believe in Inspect and Adopt, estimation is one key attribute to check how team’s confidence level on the product domain and technology stack is improving at regular cadence.

“Both optimists and pessimists contribute to society. The optimist invents the aeroplane, the pessimist the parachute.”

― George Bernard Shaw

Deep dive into Simplicity – “The Art of Maximizing work not done is Essential”

I was recollecting the “Agile Manifesto: The Twelve Principles…” and was wondering WHY “Simplicity- the Art of Maximizing work not done is Essential”, is called an “Art”, while other principles aren’t ? Why should we maximize the amount of work not done?

 

agile

 

When the organization that I was working for started the agile transformation, I was very keen and excited to see how things unfold during the agile adoption journey. Some of the key aspects that I spotted during this transition phase were prioritizing the features, picking up only enough items that are doable in an iteration, focussing on doing the essential design that suffices the functionality for the iteration, white board design discussions and capturing the summary in the form of pictures/bitmaps etc.  In the trust of meeting the iteration goal, we strived hard to imbibe simplicity by looking out for things that do not add value and maximized them to get rid of all of the non-value add activities.

As I continued my journey as a Scrum Master and an Agile coach, I could correlate this  principle to many things that we do every day and appreciated that practising this principle is an “art” that one needs to truly master and is a natural way of doing things using common sense.

Let us take an example of a Microsoft Word or Excel, there are hundreds of features available on the applications out of which we barely use 20-30%. The other 70-80% do not add real value to the product. The product owner who decides what features need to be built into the product, needs to constantly analyse and prioritize whether the said feature is a “must have feature” or a “nice to have feature”. Once we arrive at a list of must-have features, we can safely put away all the “nice to have features” into the “maximize the work not done” bucket.

The more one maximizes the “work not done” bucket, one can nail down on the “fewer valuable features” that deliver the highest business value and this is an art that the Product owners or Product Managers need to master. It is just how the inner beauty of an artefact comes alive each time you polish its surface to remove the dirt.   This reminds me of the key aspect of refactoring the code continuously in a series of small steps to keep it clean, easy to understand and modify

This principle reinforces what Jeff Patton’s says as: “Maximize the outcome and minimize the output.” What it really means is that we need to focus on the outcome rather than the output. Concentrate on the features that would help the customer appreciate the “outcome”, which ultimately may have no correlation with the number of features producing the “output.” The bottom line is – instead of maximizing the output features, focus on the outcome.

I come from a developer background where I started my career as a software engineer, when I think of my good old days of a developer when I was during my initial days of development, whenever I had to develop a new feature, I often used to check if there exists a similar feature and if I found it, I used it to save time! The result of this was manifested as a performance or some other issue that reveals during the testing phase, and then I remember spending hours together to find the root cause that takes back to the enormous lines of not-needed code that has been embedded into the files due to the copying of the existing code base as-is. This drives me back to this basic principle:  Think about every single line of code you write -is it really required? My simple reflection of this, and many such similar incidents, is that maximizing the “not needed code base”, is an art! The art has only one rule – keep your code clean and simple!

Think about the design and the architecture of any application. It reminds me of Kent Beck quote, “If simplicity is good, we’ll leave the system with the simple design that supports its current functionality”. Identification of the essential bare minimum elements and putting them in place and minimizing the dependencies and letting go of the extra things is again an art. This makes me think of the modularity aspect that makes the code base simple and easily extendable in a plug and play manner.  This design aspect also reminds me of the “KISS” strategy that stands for “keep it short and simple”, “keep it simple and straightforward “or  “keep it small and simple”.  The design we make should be so simple that it can be understood by anyone easily.   Find the simplest way of conveying the same thought process.

More often than not, we see that while writing code, we come across comments added to the code which are as big as the actual code.  What we must try is instead of writing comments which are as long as or longer than the code base, give importance to the coding standards and coding style. For example, the naming conventions could be written in a way which speaks what your code really intends to do. Add longer comments only when appropriate, and try to keep the comments simple and let the code speak for itself!

I feel this principle could be questioning each and every artefact we capture! Capture only those artefacts that are indeed required for development of the product increment. Think of every line of code you write, every single documentation that you produce, example it could be a user manual, design document, requirement document, test case document, project plan document etc. Ask one question- whether the product can live without that artefact, if yes, move it to the “Non- value add bucket”.

Think of every manual step, how much effort and time goes into that. Maximize the amount of work not done, in this case, the manual intervention steps and find ways to automate code, build scripts, testing, installation etc. that aids in doing things fast and saves time and effort.

If we reflect at the day-to-day things that we do, there are few practices that help imbibe this principle easily. Meticulous backlog refinement helps in maximizing the non-value added features and eliminating them. Emergent design promotes building only the required architecture in par with the features and encourages to keep the design simple with only the needed part.

Giving importance to working software artefact in Agile helps in doing away with unnecessary artefacts that are otherwise used as a measure of the progress. Progressive elaboration of requirements during small and frequent planning sessions helps in doing away with heavy upfront planning. Engineering practices like Test Driven Development enables the developers to write just enough code to make the test pass, not even a line more. It helps in preventing gold plating and unnecessary code and feature creep.   Use the existing standards, proven solutions instead of reinventing the wheel.

This agile principle lends itself to one of the key elements of Lean -“Eliminate Waste”- by “maximizing the non-value added part” so that a continuous flow of value can be achieved by optimizing the value delivery chain.

The best way of instigating this principle in your daily work is to ask a question every time you make a decision, “am I getting value by doing this?” If yes, move it to the “Value Add” bucket else push it to “Non-Value Add” bucket. The art lies in delivering the highest value with the least number of items and I perceive this as a real “art or skill” that comes through experience.

I would be glad to hear and learn from readers how they perceive this principle.

Maximizing Business Value with Agile Portfolio Planning

In current time 90% of fortune 1000 companies are practicing some form of agile practice. Agile is no longer for fringe; it is mainstream. Most organizations adopt agile practices from bottom-up while leadership/management plays role in creating environment (culture) for agile adoption. We seems to have some experience, knowledge (evolving) about how to solve mystery of agile adoption for delivery teams starting at individual team level and scale it to program level; but most organization still follow traditional practices at the top level for managing portfolio, determining roadmap, budgeting and funding projects, etc. This creates conflict in different sets of practices originating from different mind-set.

 

Traditional Portfolio Management Definition (Wikipedia)

Project Portfolio Management (PPM) is the centralized management of the processes, methods, and technologies used by project managers and project management offices(PMOs) to analyse and collectively manage current or proposed projects based on numerous key characteristics. The objectives of PPM are to determine the optimal resource mix for delivery and to schedule activities to best achieve an organization’s operational and financial goals ― while honouring constraints imposed by customers, strategic objectives, or external real-world factors.

 

Traditional Portfolio Planning Attributes

Portfolio planning is always about matching demand and supply; in traditional portfolio planning we ask the question – this is the demand now let’s find out how we meet this demand. Traditional portfolio planning is top Down, Centralized Annual Budgeting, Focuses on Governance, Compliance, and Control. It is run by PMO focussing on Budgeting, Auditing, and Resource Allocation; has detailed upfront planning, fixed date, fixed cost (budget allocation), full team allocation (resource utilization), and multiple projects in parallel. We love excel sheets and use complex electronic tools. Teams are created to do the projects; group of people are brought to the project – putting different people each time expecting predictable outcome with high quality. Success is measured as On Time, On Budget with scope (Conformation to Scope).

 

Challenges of Traditional Portfolio Planning and Execution

“We have too many things to do”, “We are doing some many things in parallel”, “Your group is too slow to react”, “we are slipping and not able to catch up”, “Why there are so many defects” – And On and on… Does this sound familiar?

 

And our reaction to this is – Tighter control through rigid change request process; More Detailed Planning.  All this is to create an illusion of Predictability or an illusion of Control. But is this Working? Honest answer “Not really” then the Next Logical Question is – What is an alternative?

 

Agile Portfolio Planning

Which is based on approach of Active Planning for Maximising Value. In Agile Portfolio Planning we frame the demand and supply question differently – rather than Desire Vs Capacity – We ask Desire Based on Capacity and hence maximizing value based on capacity. Desire comes from – Market, Executive, Product Managers based on vision and strategy of the organization prioritized in portfolio of items – capacity comes from teams (fixed) and programs (teams @ scale for governance) And Alignment between What We Want and What We can do is by answering that key question “Desire Based on Capacity” and answering that question not one time but @ regular cadence aligning two opposing forces ‘What We Can Do’ and ‘What We Want To Do’

dadadad

There are 4 steps to Active Portfolio Management – Agile Way to maximize value creation for organization.

 

Supply – What We Can Do

You start with determining capacity based on unique portfolio of discrete non fungible teams; we consider Product unit is one team iteration and No of similar size stories is unit of measurement.

So iteration capacity = average stories per team multiplied by total teams. Key is to make All Work is visible to account for it and not hide/ignore.

 

Demand – What We Want

Identifying demand by all work as prioritized (insure that effort matches the benefits) with single funnel for each portfolio; again the best practice is All work is made visible.

 

Active Planning

Practice followed is Desire based on capacity – Capacity is fixed so optimize the return on team – Highest value per iteration; Bring Work to Team rather than bring group of people to work. This helps with keeping the high performance team intact and leads to higher sustainable performance over long period of time. Strive for Return of Portfolio Teams.  Plan in 3 quarter horizon with cadence of quarterly planning event to do continuous high level of calibration. To take care of need for changing capabilities, skills – long term strategy should be to match the needs to ability by planning for training, etc.

 

Continuous Optimization

You have to work on optimizing the portfolio items through continuous prioritization/re-prioritization at regular cadence. Strategies or considerations for continuous optimization at the portfolio level are

Investment considerations

  • Sunk Cost
  • Cost of delay
  • Cost of early exit

Option Value

Nesting

Portfolio rather than project optimization

Lifecycle management

Avoid being precisely inaccurate.

 

To have an enterprise agility; organizations adopt agile and lean practices for product delivery units; but not having similar practices for work being done by the top management can create confusion and conflict. Agile Portfolio management is based on Agile and Lean values and principles and help team harness knowledge coming out of changing business, organizational, technological scenarios to maximize the value creation. Organization management and leaders have obligation to lead by example and exhibit behaviours aligned to culture of agility by doing portfolio planning the agile way to maximize value creation.