Scrum Source

Transitioning to Agile: Five Success Factors

Transitioning from a waterfall process to an Agile framework like Scrum can be a daunting task. However, you can make the effort a whole lot easier if you have a good idea of what needs to change – beyond getting rid of waterfall – if you were to take the plunge for your organization.

I have found that there are five broad success factors that need to be addressed in order to successfully transition to Agile. Without addressing these factors, you may be able to make a transition but the viability of the effort is likely to be short-lived.

Below is an illustration of the five success factors:

Although all five success factors are essential, Culture has a greater impact overall...

Technology

In this context, we are referring to technology as any process, tool or material that helps solve a problem. Typically, this is the element companies tend to focus on first – and unfortunately often ends up being the only factor they focus on.  Software tools like ScrumWorks, Mingle or  Jira’s Greenhopper are good examples. So is frameworks like Scrum or XP; they all help enable teams to be successful and solve a problem. Unfortunately, by ignoring the other factors, transition efforts suffer.

Organizational Design

We use the term ‘design’ here rather than ‘structure’ as this refers not only to the organizational structure of the organization, but also the physical (architectural) outline.  If an organization is very hierarchical with several layers of decision-makers, your transition efforts will be challenging. Also, if resources are located in remote locations or have a clear ‘office preference’ where open space and collaboration are frown upon, you will have a hard sell on your hands. But don’t ignore this – you will lose a significant piece of Agile’s potential if your company’s organizational design is not addressed.

Leadership

This can be one of the most important factors; leadership holds a lot of influence as they ultimately pay the bills and can allocate money, time or people to your transition efforts. Does leadership actively sponsor and support your transition efforts? Do they lend their influence to help Agile grow and prosper in your organization? Without leadership support, any transition effort is going to be difficult to sustain. If senior leadership is not quite on board yet, look for other influential leaders at other levels. However, if you find that you have zero support within the company’s leadership, I would categorize this as fatal to your transition efforts.

People

Ultimately, your organization’s employees are the ones that are going to make this work or not. If employees thrive on working in the basement alone, abhor team work or are not open to new ideas and ways to work, you are going to have a tough battle on your hands. Resistance is inevitable as change is tough for everyone, but you’re going to need some energetic, motivated ‘agilistas’ in order for any Agile transition effort to work. Look for people with energy, enthusiasm and low egos – you need to be humble in order to complete a successful transition.

Culture

Which leads us to the last – and most influential – success factor: culture. The organization’s culture has typically been developed over many years, so this is hard to change. But if you recognize what you’re dealing with, you are more likely to design a response to fit the situation. Agile thrives in a collaborative, team-based culture in which transparency is obvious and people are not afraid of making mistakes or letting other people in the organization know if there are problems (in fact, ‘failing fast’ is a virtue as it reveals concerns early on in the project).

If you find that your organization extols values in stark opposition to Agile principles (i.e. command and control, fear of failure, ‘CYA’ mentality, etc), this is something that needs to be addressed if you’re going to have any hope of a successful Agile transition.

In future posts, we will look into the success factors further and discuss approaches for transitioning to Agile in a way that fits your company’s unique situation.

How Prescriptive is Scrum?

This is a question asked frequently, especially by larger organizations that are struggling with scaling. On one hand, they want to keep the inherent flexibility and empowerment provided by Scrum – they have seen the great results that an engaged team can produce. At the same time, they need to keep consistency between the teams, create a common structure and scale a portfolio of projects. When team members want to make changes, how much leeway are they granted?

The short answer is ‘it depends’. And I don’t mean to punt, but it truly does depend on the nature of the proposed change. Obviously, I am biased here, but this is an excellent example of where an experienced ScrumMaster is extremely valuable.

As the ‘owner of the process’, an experienced ScrumMaster will know where there is some give and where one has to be rather strict. (This will depend on the maturity of the team – no universal rule here).

Make no mistake: Agile will lose a lot of its power and effectiveness if terms such as ‘team empowerment’ and ‘self organizing teams’ become perceived as merely management lip service or fancy buzzwords. On the other hand, if we go to the other extreme and let teams implement whatever flavor of Agile they want, this is sure to kill scalability, generate zero visibility and essentially unusable metrics, which is crucial to be able to continually gain management support, especially in the crucial pilot phase of an enterprise implementation.

Even though Scrum advocates empowerment, this does not mean anarchy.

So what to do? My answer would be that the team has to ‘earn’ the right to modify elements of the process. This means that at the outset, we aim to follow the process as closely as possible. However, as the team matures and the ScrumMaster is able to assess where additional gains can be made from making tactical changes to the process, this is an option that should be on the table.

Don’t get me wrong – the core fundamentals of Scrum need to be there – there should always be a daily Scrum, a Sprint Review, a Retrospective, etc. Certain elements are essential to a proven framework that needs to be there in order for this to work on a larger scale. However, if the team truly feels that they can be more productive having a 3-week Sprint rather than a 2-week Sprint, I don’t see a reason why that should not be an option to consider.

What makes Agile so compelling is that it is steeped in common sense.

Your implementation should reflect this spirit – It does not make sense to on one hand preach ‘empowerment’ and rollout a process that does not leave any room for independent thought. Similarly, providing teams with responsibility to make decisions does not mean they don’t have a boundary framework to work within.

How is Scrum implemented in your organization? Does each team have their own variations or is there a strict standard that is followed universally across all teams?

The Art of Scrum Planning

Planning a release using Scrum requires input from the entire team

In traditional project management, the project plan – sometimes just called ‘The Plan’ – is the most important artifact of the entire project.  This is the single source of truth, the beacon amid a cloud of uncertainty that will clarify to stakeholders when each major milestone hits and the date by which – come hell and high water – we go to production.

In Scrum, planning takes on another meaning entirely.  Some snicker when Scrum and planning are brought up in the same sentence. “I plan to re-plan” says a popular t-shirt at a recent Agile conference. Yet, as much as we’d like to avoid being deterministic and pretend we can predict the future, business sponsors and product owners are going to need some idea of when a given product can hit the shelves. Marketing campaigns need to be aligned, strategic players need to be involved, messaging need to take place – often many months in advance. Simply stating that “we’ll know it when we get there”‘ is simply not acceptable.

So how does project release planning work using Scrum?

First, the team priotitizes the stories. There are a number of ways to prioritize the user stories, but ultimately this is the responsibility of the product owner. Business value is often a critical factor in this regard, but so are elements such as risk associated with the given story and dependencies on other stories. After prioritizing the user stories, the team has a good idea of the order in which the stories should be implemented.

Once the stories have been prioritized, the next step involves estimating the stories in terms of relative story points. This ensures that the team has a general idea of the effort required to implement a given story. Granted, this is not going to be a to-the-hour accurate estimate, but it will give the team a general idea of the effort required to implement each story.

Finally, the team will divide the total number of story points with the team’s historical velocity. For instance, if it is estimated that the total product backlog consists of some 60 story points and the team’s velocity is 15, it would be a fair estimate to state that the release would take 4 sprints for a product release. Now, it may be wise to add an additional hardening sprint to make sure documentation, lagging system test cases and other loose ends are tied up – but the overall estimate would be a fairly accurate one.

So what would be the duration of the project of this size? This would depend on the iteration length, but let’s say your sprint duration is two weeks. Given 4 sprints to work on the 60 story points and an additional hardening sprint, we’re looking at an overall duration of 10 weeks.

Is this going to be 100% accurate all the time? Like any estimate, this should be viewed as an educated guess and no guarantee. Nevertheless, for planning purposes, I am confident you will find this estimate to be just as accurate – if not more so – than the estimates typically provided in traditional waterfall processes.

Knowing what’s “Good Enough” is first step of getting things done

Prevent Analysis Paralysis by avoiding a quest for Perfection

"The way to get started is to quit talking and begin doing." - Walt Disney

Traditional waterfall methodologies require that stakeholders identify any and all requirements up front. The idea is that this will ensure that you know everything necessary to properly plan resources, schedules and critical dependencies. Of course, as anyone who has ever managed a project will testify, this is a noble idea but unfortunately hopelessly unrealistic.  There are always going to be factors that are overlooked at the inception phase. Why? Because market conditions are constantly changing, which necessitates the need for a flexible approach.

Agile gets this – in fact, it encourages the idea of ‘good enough’ so that you can stop analyzing and start doing. “Good Enough” does not mean it’s sloppy or that it’s not thought through. It does not mean it’s hastily put together. Rather, it means that you have spent time as a group thinking through and discussing the various issues of the project to the point where there is a decrease in incremental return for every unit of time spent.

When you get to this point – the ‘Last Responsible Moment” – it is time to start doing. It may feel uncomfortable at first as you realize there are still going to be areas that are not ‘fully baked’. But the point is that by starting the work and doing the things that are clear at this time, you can figure out the rest later.

This idea will take some time to get used to for traditional project managers. It’s not the way PMPs were taught – it goes against the very principle of comprehensive up-front planning. But in today’s fast-paced business environment, it is the most practical way to manage projects – at least if business value is of concern.

My advice to you is not to dip your toe in the water. Instead, dive in and trust the team to figure it out.

Scaling Scrum

Scrum scales with careful consideration

The myth is that Scrum is merely a methodology to be used for smaller projects.

This is a fallacy – many organizations have very successfully scaled Scrum and continues to have success with Scrum in an enterprise context. But Scrum does not scale intuitively; many of the elements of this methodology that makes it so successful such as collocation, daily scrums and the close involvement of key roles are factors that do not easily scale without some careful consideration.

Here are some ideas you should think about before scaling Scrum in the enterprise.

Scale the Scrum Roles

Scrum is dramatically different from waterfall in that roles such as ScrumMaster and ProductOwner play crucial roles that cannot be substituted with extensive documentation. Therefore, when scaling Scrum, make sure you also scale the roles of ScrumMaster and Product Owner. One way to ensure you have the proper representation of a Product Owner for multiple teams in several locations is to designate “Product Owner Proxies”. A proxy would have the same day-to-day responsibilities of a traditional Product Owner and help the team answer questions that come up during the sprint, but would be less involved in strategic work.

Create One Product Backlog

Instead of having multiple backlogs across many teams, consolidate all work on a given project into the same product backlog. This ensures that there is a common vision and understanding of the work remaining within the given project without having to manage multiple, disparate product backlogs.

Proactively Manage Dependencies

In large-scale implementations of Scrum, it is even more important to focus on identifying dependencies between and across team ahead of time. One way to help achieve this is to always plan 1-2 sprints in advance – in addition to the current sprint planning session. Obviously, your level of visivility will be less clear for these forward-looking sprints, but they do provide a good idea of the work that is coming up. By ensuring all teams adhere to this practice, a better vision of upcoming work can be communicated across the respective project teams.

Establish an Integration Team

An integration team consists of key technical members from each respective team within the project. By having members of the integration team meet on a regular basis, a common understanding of the current – as well as upcoming work – may be affecting other projects can be identified. The integration team needs to meet on a regular basis, but meeting more than every 1-2 weeks should be sufficient.

Scrum of Scrums

The Scrum of Scrums is an affective way to communicate findings between the different project teams. This team, although technically a scrum team, does not meet every day and their meetings should not be limited to 15 minutes. The key here is that during these Scrum of Scrum meetings, each team member reports to other members on any developments within their respective project that could affect other projects. In other words, this is not a status meeting – but rather a session focusing on items that may affect other projects.

Scrum Does Scale

Contrary to what may have been conventional wisdom a few years ago, Scrum is quickly becoming an enterprise-wide project methodology with a proven ability to scale across the enterprise. Although some modifications and enhancements of traditional Scrum techniques may be required, there is no reason the many benefits of Scrum cannot be implemented in larger organizations.

The PMP-trained Project Manager as ScrumMaster

When converting to Scrum, the role of ScrumMaster is most commonly transferred to someone previously in the role of Project Manager.

Project Manager as ScrumMaster

Conflicting personalities of a Project Manager and ScrumMaster

In many ways, this makes a lot of sense – the project manager is used to working with people with a diverse set of functional and technical skills, they are typically people with strong communication skills and if they’re worth their salt, they should have a solid understanding of the value each project brings to the organization. These are all important attributes of a ScrumMaster as well – all well and good.

But the ScrumMaster role is radically different from the traditional PMP-trained Project Manager. In Scrum, teams are self organizing, and there is no PM to assign tasks to a resource based on clearly defined roles. Instead, team members (pigs) assign work among themselves and the ScrumMaster ‘facilitates’ this process, rather than dictating who does what — and when.

Can this be scary, downright frightening to a classically trained PMP?

You bet it is. How will the work ever get done? Who ensures that each person works the amount of time necessary? Who’s handling all the quality/scope/budget/resource constraints of the project – and who’s holding people accountable?

Read More