by Robert Smith, Agile Sr. Consultant
What Pitfalls to Avoid
The success of Agile Framework adoptions in the software development communities over the past few decades has initiated a wave of interest for companies to leverage the Principles of Agile outside of the traditional software development domain to other business units, such as Finance, Marketing, and Human Resources.
Recently, companies have started to apply or adapt Agile principles in other areas of the organization, such as Marketing, Customer Services, and Human Resources. These cross-departmental adaptations of the Agile principles are likely to continue at a rapid pace as agile, and its adaptable value-based benefits become more apparent to businesses. This article focuses on the potential pitfalls that organizations should be aware of as they make the journey.
However, many companies will pay a high price as they struggle to adapt Agile principles, despite the existence of the Agile Manifesto for the past 18 plus years, and numerous successful adoptions by many companies. “Imitation Agility” is the price that many companies will pay when trying to implement Agile principles within non-software development business domains.
“Imitation Agility” is operating under the notion that they have fully integrated and adopted applicable agile principles within business domain processes, all to find that they have fallen short when trying to extend their business processes across or into other business domains. These Artificial adoptions result in failures because, during the implementation of the agile principles, many business units will focus on current process practices (As-Is) versus expected outcomes (To-be). It’s much easier to focus on the refinement of the existing process practices, and not the expected results, because it’s all you know and what you’re most familiar. After all, there are no real consequences to distract you when you’re trying to refine something you already know.
To get the best out of your transformation, it’s critical to adopt an “Outcomes Approach”. That means focusing on the elements of the expected outcomes and not the good, bad or indifferences of the current practices.
The foundation of any agile adoption approach should be to embrace and quickly adapt to change; the best way to embrace change starts with awareness followed by understanding the change, and quickly adapting to the change. Both within and outside of the software development domain, these changes can be in the form of environment, competition, market conditions, customer and resource requirements, and even world events. Just as U.S. Marine Combat Training teaches combat soldiers to assess, cover and move; agile methods advise adopters to “inspect and adapt” to the onset of unknown changes.
Many businesses seeking agility outside of software development are not able to do so mainly due to their adoption or inheritance of practices or rules from the software development domain that are not applicable to the business domain where they seek agility.
Instead of blindly mimicking Scrum cadences and ceremonies from the software development domain, business agility teams should be looking to more experienced agile practitioners with the mental models and experience in handling the abstract concept of inspect and adapt in terms of business process modeling to lead their Agile Transformation. This will enable teams to accelerate their implementation of Agile and avoid the many pitfalls associated with implementing Agile in other than software environments, and better utilize the agile principles and leverage the abstract ideas of the Agile Manifesto.
When leading the implementation of adopting Agile principles in the business domain, companies and the individual business units must remember, Agile is a solution to achieve a desired outcome. Before beginning any Agile transformation, business units must identify what outcome(s) they want to accomplish within their business and use Agile and its adaptable principles to achieve those outcomes.
“Our goals can only be reached through a vehicle of a plan, in which we must fervently believe, and upon which we must vigorously act. There is no other route to success.” — Pablo Picasso
Organizations can realize actual benefits from business processes that span multiple departments when focusing on outcomes during the journey to Business Agility. These benefits come on the form of; enabling cross-departmental resources to work more cohesively, removal of business and functional silos, faster response to process breakdowns or deficiencies due to unforeseen change, and better overall cross-functional communication and collaboration.
Robert Smith is an accomplished high energy PMO/Agile Transformation leader with more than 20 years of experience in Strategic Program, Project, and Portfolio Management in fast-paced environments. Demonstrated track record of delivering business transformation, agile methodology adoption, software development, and enterprise technology integration projects.
by Steve Hamilton, Agile Client Service Director
The construction of the Empire State Building vs. a routine system upgrade. Can your project plan hit the broad side of a barn?
On a tour of the Empire State Building, I was struck by the project plan for its construction. My family made fun of me as I focused on a Gantt chart instead of looking at the hundreds of interesting construction photos and articles posted around the gallery.
I am used to massive project plans with hundreds or even thousands of rows filled with complicated dependency diagrams, resource utilization, percent complete, etc. So, I was surprised to have discovered this plan had none of that.
Yet somehow, they were able to build the largest building in the world—and do so on time and on budget.
To get a sense of the sheer scale, let’s compare the Empire State Building’s (ESB) construction with recent software project I was involved with: a routine system upgrade.
- Budget: The Empire State Building’s budget in 2018 dollars was approximately $675 million. The system upgrade? Roughly $10 million.
- Peoplepower: ESB had a team of 3,400 or about 7,000,000 person-hours. The system upgrade had about 200 people or 800,000 person-hours.
- Length: ESB was completed in 410 days. The system upgrade is expected to last 730 days.
- Expectations: ESB was delivered on time and about 20% under budget. The system upgrade has been delayed by six months (a 25% increase in the timeline so far), and the budget has already been increased—twice.
- Documentation: ESB had 47 rows on its project plan (66, if you count subtasks). The system upgrade has more than 40 project plans (I) representing tens of thousands of lines (II).
To summarize, with a budget only 1.7% as large and using only 6% of the resources, this routine system upgrade took nearly twice as long to complete, ran over time and over budget, and had a project plan that was approximately 1,500% larger.
What’s the difference?
Many software projects take a command and control approach. This necessitates massive project plans to ensure that the project manager is aware of every important project detail in order to map out the dependencies, understand whether the project is on schedule, and within their budget.
Sadly, these plans often contain a high level of precision with very little accuracy. In effect, we are trying to hit the proverbial “broadside of the barn,” yet we end up putting a very small hole in the wrong barn. Instead of realizing that we missed the mark entirely, we congratulate ourselves on our precision.
So, what do we do?
In many cases, these highly-precise project plans are created out of fear and mistrust. It’s an attempt to control an uncertain future.
If we can’t plan these details out and map our dependencies, how do we know our team will do the right thing? How can I know we will be done on time? How will I know how much it will cost?
There’s a better way. For starters:
- Accept that we can’t predict the future with any level of precision and decentralize control and/or execution to allow for rapid response to unforeseen events. See Predicting The Financial Crisis.
- Accept that project plans and artificial deadlines don’t motivate people or guarantee results. Hire skilled people that you trust. (More on this in Daniel Pink’s piece on motivation.)
- Let people do what you hired them for! This is known as “servant leadership.”
Maxims like these are great. They serve as a guide when making decisions as you can test yourself against them. However, critical questions still remain, such as: how much will my project cost? How long will it take, and how many people do I need? How will I know if I’m on track?
Never fear: All these questions have answers.
Drawing from lean and agile methodologies, we can use empirical (evidence-based) data to formulate their answers. For example, to plan cost/timeline/staffing for the system upgrade we start by identifying a comparable project. Do so by looking at your own organizational history, consulting the experts in your organization, or working with your vendor to understand similar implementations they’ve done.
Once you’ve found a comparable project, base your plan on the relative size of your proposed project. Is it half the size? Twice the size? This will give you a highly accurate (yet not precise) budget. (Note: If it isn’t half or double you might not have picked the right comparable project.)
Finally, how do you know if you’re on track? This one is easy, and it comes directly from the world of lean. Get out on the floor, and talk to your team. It’s known as Gemba (“the real place”), and it’s a highly effective way to not only find out whether you are on track but ensure that you stay on track by identifying and eliminating risks and problems early and often.
On a 200-person project, it is reasonable to walk around and talk to people. Focus on providing visibility of the work. On the Empire State Building, they had the benefit of a giant structure that everyone could see every day. In the software world, we can use visual tools like Kanban boards and demonstrations of working software to effectively provide status without adding undue overhead.
Which brings us back to our barn. When trying to hit the broad side of a barn, you’re better off putting a large hole in the correct barn than a tiny hole in the wrong one.
Steve Hamilton is an Agile Transformation Consultant specializing in Product Management in the Agile Practice at Plaster Group. He specializes in lean and agile methodologies and is passionate about aligning business and technology groups to deliver the “right” thing, at the “right” time, and in the “right” way.
Follow Steve on Twitter: @stevenhamilton.
Plaster Group had a great time attending the awards ceremony for 2019 Washington’s Best Places to Work at T-Mobile Park, sponsored by Puget Sound Business Journal’s. We all enjoyed the energetic crowd excited to be there as they represent their employers. We were all very thrilled to be back again. This year, Plaster Group made it to the top 20 list for medium-sized businesses! This success is all due to the amazing employees that make us who we are. A huge thank you to our employees that came and celebrated this incredible achievement. Until next year!
Plaster Group employees and their families joined forces for the 3rd year in a row to volunteer at Northwest Harvest! We worked together to help pack 14,800 pounds of apples on a Saturday morning of August 24, 2019. This is equivalent to 11,390 meals! As we continue to make it a point to volunteer each year as part of our commitment to our 3 C’s – Consultant, Client, and Community – it is important to us to not only to serve our clients but the community where we live!
by Aki Namioka, Sr. Agile Consultant
Estimating agile projects, especially within an organization transitioning from waterfall to agile, is a topic that can be rife with tension and opinions.
One source of tension is the desire to replace waterfall planning with something that is just as tangible. On a typical waterfall project a Project Manager has filled out a Microsoft Project file with ALL activities listed– often months ahead of time. The estimates are usually in days or even hours. However, as soon as this Project file is published, it is probably out of date. Spending days or even months on creating this Microsoft Project file is characteristic of a heavyweight methodology.
Agile, however, advocates lightweight methodologies. Scrum teams often use story points to estimate the work instead of hours/days. It is much easier for an agile team to estimate a 5-point user story, rather than estimating a 3.5 day feature. But a confused manager may try to map the story points to something they are familiar with and ask, “How many days is one story point?”
What the manager probably wants is the answer to these two questions: “When will the work get done?” and “How much work is left?”
The key to successful agile estimating is to find a balance between the need of the organization for transparency into the status of a project, and the agile team’s desire to stay lean and lightweight.
Story Points, Planning Poker, etc.
Most Scrum teams have adopted story points to estimate work, and use planning poker, or something similar, to reach consensus on the effort required to finish a user story. However, even though this practice is popular, it is not mentioned in the Scrum Guide. The Scrum Guide only says that a Sprint Plan should be created at the beginning of each Sprint. It is up to the team to decide the amount of work that be taken into a Sprint Plan.
That said, story points and planning poker are popular for several reasons. Story points are a simple lightweight system. Each team can create its own scale for estimating the effort that goes into completing a story. If the Fibonacci sequence is used to assign points (i.e. 1, 2, 3, 5, 8, 13, …), it is even easier for teams to use this system for estimation. Planning poker gives each team member a voice in estimating the effort. It will also quickly show if there are discrepancies on the teams for what implementing a story entails. The simplicity of both practices is in keeping with the agile culture of Lean practices and values.
Release planning and affinity estimating
With story points and planning poker, there is still the issue of answering the manager’s question: “When is it going to get done?” Though creating an up-front project plan for an entire project is impractical and inaccurate for most projects, many agile teams will do a lightweight release plan. This release plan will produce a mapping of user stories to Sprints for about 3 months. The Scaled Agile Framework (SAFe Ò) has a version of release planning called a program increment (PI) planning. To support release planning, the team can do a quick first pass on assigning story points using “affinity estimating”, or something similar. A team can sort all the user stories that are targeted for a release from smallest to largest. Keep in mind that this is easier for teams that understands their velocity. Once the stories are sorted it is easy for the team to put them into story point buckets of 1,2,3,5,8, … points.
After a Release Plan is created, the team can still revise the story point estimates while they go through their normal backlog refinement and Sprint planning.
Why do hours?
Some agile teams still want to add more granularity to their work estimates and will often add hours to the subtasks for user stories. This is often done during Sprint Planning, and tools like Jira will show a Sprint burn-down chart based on remaining subtask hours. This can be a useful metric for a team, to see how much work is left to complete a Sprint. This can be useful for new teams that are unsure of their capacity and velocity. However, this level of granularity does take more time to produce, so an agile team should weigh the cost-benefit of producing estimates at this granularity.
Experience with estimating:
As an agile practitioner, I have two stories about points and how my teams handled them. These stories illustrate why story points may or may not be useful.
I was coaching a Scrum team that had been together for a couple of years, and we were working on adding features to a product that had been in use for several years. We were stable enough that we planned an average of 5 story points per person per Sprint. At one of our Sprint Planning sessions a developer said, “Why don’t we just pull the next 6 stories?” He explained, “We’ve been averaging 6 stories per Sprint for awhile”. I looked, and sure enough, he was right! As the team had matured, we were consistent in our velocity as well as consistent in story sizing. His insight saved us lots of time in subsequent Sprint Planning sessions.
Another team was transitioning from Scrum to Kanban. Before our transition, we discussed which practices still made sense as we transitioned to Kanban. One practice the team decided to keep was story points. We were working on a new product with new technology, and the team felt that continuing the practice of pointing stories would help us create consistently sized stories.
Agile projects should decide what level of estimation makes the most sense and meets the needs of the organization. Whatever method is selected, two things should be considered:
- The estimation method should be as lightweight as possible and still provide the team with information they need to make decisions about Release Plans and Sprint Plans. This could mean no estimates at all with a stable team.
- The method of reaching consensus should give everybody on the team a voice in the estimation decision. Planning Poker is the most common method for teams using story points, but other practices exist, such as affinity estimating or “t-shirt “sizing.
A competent agile coach should be able to guide the team to adopt the estimation method that works best for them. It may change over time as the team matures. There is no agile practice that is cast in stone, including estimation methods.
by Aki Namioka, Sr. Agile Consultant
Agile consultants often work in large IT organizations, and are frequently asked, “What is an Agile PMO?” The answer seems simple: “A PMO that supports Agile”.
The real issue seems to be “How does a PMO fit in an Agile organization?” Traditionally, a PMO is the owner of the project management process, which includes creating project plans, tracking and mitigating risk, managing budgets and other project resources, and reporting status to project stakeholders. They also manage “stage gates”, carefully guiding a project through the entry/exit criteria for each phase of a project. This type of project management tends to work well in the “waterfall” paradigm where projects typically go through a sequential series of phases that have clear entry/exit criteria. E.g.
However, in the agile paradigm some of the traditional roles of a PMO change. Here are some changes that a PMO may encounter:
- Project Plan – on agile projects, the project plan is created as a whole team effort, with the Product Owner guiding the priority and release planning. Release planning is followed up with regular iterations or Sprint planning, which is often facilitated by the Scrum Master.
- Project Phases – agile projects deliver business value in small incremental pieces, where a little bit of design, development, test, and deployment happens at the end of short regular iterations. This is in contrast to a sequentially phased approach illustrated above.
- Delivery Process – self-organized agile teams control how they deliver projects, including changes to processes through constant retrospection and adaptation.
Because many of the traditional responsibilities of the PMO have been shifted to self-organizing agile teams, some organizations have redefined the role of the PMO to focus on responsibilities outside of core team activities e.g. budget, risk mitigation, and status reporting. However, this falls short of what an Agile PMO could be. Instead of reducing the responsibilities of a PMO in an agile organization, the PMO should embrace agile.
Reading the “Agile Practice Guide”, jointly released by the Project Management Institute (PMI) and Agile Alliance, it seems clear from their perspective that the definition of an Agile PMO is a PMO that supports agile. A traditional PMO may wonder, ‘What does this mean and how do we evolve to become agile?’ Mike Cohn, a founder of the Scrum Alliance, wrote an excellent article titled “The Role of the Project Management Office in Scrum”. He suggests that a PMO could be responsible for Scrum & agile training, staffing and training agile coaches, and guiding an organization to adopting an agile mindset. In short, the Agile PMO would be responsible for the organization’s agile journey, in the same way they have been responsible for the care and feeding of the traditional project management process. Whether the organization is just starting its agile journey, or has already adopted agile, an Agile PMO would be supporting the organization’s needs every step of the way.
However, given the reality of many PMOs, we have to acknowledge that a traditional PMO, like any other organization going through an agile transformation, needs the training, coaching, and support of the organization to be able to fulfill its role as an Agile PMO. They have the additional challenge of not only going through their own agile transformation, but also ensuring that they have the right people to guide their organization on their agile journey. Adopting agile is not as simple as moving from one set of processes to another — it is truly a change in mindset. A successful Agile PMO understands the agile values, as articulated in the Agile Manifesto, and will apply them at the organization, project, team, and individual levels.
As a musician once told me before a performance “own the mic!”
So, PMOs – “own agile!”
by John Pangilinan, Sr. Agile Consultant
One of the biggest challenge in any development project is deciding what work items should be delivered first. In an environment where you have multiple stakeholders from different parts of an organization advocation, sometimes demanding, for their work items to be done first, it is difficult to be able to decide objectively in what sequence work items need to be done in. In this situation it is important that teams feel that their needs are heard, but how does one do that when priorities are subjective to the teams? How can leaders leverage an objective approach to prioritization?
A possible approach that teams may choose to adopt is the Weighted Shortest Job First or WSJF which is a prioritization method used to order work items (User Stories, Features or Epics) in a way that leverages feedback from stakeholders to deliver the most value in the shortest time possible. This is done by estimating the Cost of Delay and dividing it by the job size.
WSJF = Cost of Delay [ (User | Business value) + Time Criticality + Risk Reduction] ÷ Job Size
• User-business value – Do our users prefer this over that? What is the revenue impact on our business? Is there a potential penalty or other adverse consequences if we delay?
• Time criticality – How does the user/business value decay over time? Is there a fixed deadline? Will they wait for us or move to another solution? Are there Milestones on the critical path impacted by this?
• Risk reduction-opportunity enablement value – What else does this do for our business? Does it reduce the risk of this or a future delivery? Is there value in the information we will receive? Will this feature open up new business opportunities?
• Cost of Delay-helps teams understand and quantify the impact of time on outcomes. A way to calculate the time it takes to develop a new feature which includes the time spent in the backlog and what that delay will cost to your business.
Teams will be asked to estimate each of the components using relative numbers (Fibonacci sequence is often used). After which these numbers will be plugged into the formula and the work item with the highest WSJF is the highest prioritized work item.
My experience using WSJF within my own project resulted in more confusion rather than clarity. We had team members who were not interested in letting the process dictate the prioritization order of work items and instead insisted that their work items needed to be done first for one reason or another. From this experience I found that in order to successfully leverage WSJF it is important that team members are not only trained on the WSJF but are bought in to using the method no matter what its outcome is. If not, the practice become cumbersome and ultimately meaningless.
In addition determining the cost of delay is tricky. Unless you are looking at something tangible for example the cost of delaying the opening of a physical store which maybe calculated by basing the potential lost on the sales of comparable stores in the area. However in the case of software without data to base your calculations on your basically guessing.
Therefore I suggest before teams decide to adopt WSJF it is critical for the them to be educated in how to properly leverage WSJF within their organization and using a consistent approach as to estimating each of its variables. If not I fear using such an approach can lead to wasted cycles and more disharmony within development teams.
John Pangilinan is an Agile transformation consultant, experienced Scrum Master and Product Owner with over 8 years’ experience working within multiple Fortune 100 companies to build and deliver value. He is passionate about helping teams reach their full potential via empathy, clear communication and clearly defined goals.
by Aki Namioka, Sr. Agile Consultant
I. 13th Annual State of Agile Report
The 13th Annual State of Agile by VersionOne CollabNet released earlier this month, providing us with data about agile trends, adoption, and practices. For those of you who are new to this report, the data is collected through a survey that is conducted and then analyzed by VersionOne. Respondents to the survey come from all over the globe, and for the first time, less than half the respondents were from North America.
For Agile professionals, this year’s report contained some particularly interesting metrics and trends. The good news is that 97% of the respondents said their organization are using agile. However, looking back at data collected about the benefits of adopting Agile, we see are some thought provoking trends:
Though the reasons for adopting agile have been fairly consistent over the past few years, there has been a big percentage drop in perceived benefits of agile adoption in some categories. Perhaps the large drop in year over year benefits for things like “delivery speed”, “ability to manage changing priorities”, and “software quality”, could simply be a product of the increase in global respondents. For people interested in agile adoption, this trend should be something to monitor as subsequent reports get released.
In most categories it appears that the benefits of agile are performing better than the reasons organizations adopted agile. But there are some cases where it appears the anticipated benefits are not being realized or are trending down, e.g. product delivery speed.
It is fascinating that the reasons for adopting agile, and the benefits of adopting agile, are not aligned. For example, only 34% of the respondents adopted agile to “improve team morale”, yet 64% of them saw an increase in team morale as a benefit. . It appears that there are some unanticipated benefits to agile adoption.
There is also some other interesting data. Though 97% of the respondents said they are practicing agile, 48% said that less than ½ of their teams are agile, and 83% said their organizations were below a “high level of competency” with agile. There appears to be opportunities to improve in realizing the full benefits of agile adoption.
II. Realizing Agile Benefits
We can look more closely at how agile principles and practices can support the top organizational agile goals that are listed in the Report. However, it is important to note that even though we are focusing on only some of the agile principles and practices, all of the agile values and principles are important in creating or sustaining an agile organization.
2.1. Accelerating Time to Market
Delivering business benefits faster is very feasible for an organization that is moving from the classic waterfall style of project management to agile. Rather than long waterfall style analysis, design, implementation, and test phases that precede delivering any business value, agile projects deliver business value in small increments – often in regular iterations or Sprints. The key practices that supports the delivery of business value in small increments are:
Work is done in iterations (or Sprints in Scrum) on a regular cadence. Most teams select a cadence of 1-4 weeks, with 2 weeks being the ideal iteration length.
Work is delivered as “potentially shippable” product at the end of each iteration.
Work is defined as small chunks of functionality in the form or user stories. Each user story should go through an entire development workflow (i.e. dev/test) within 1 iteration.
Definition of Done is used, i.e. a checklist that needs to be completed before a user story can be considered “done” or in a potentially shippable state. This helps ensure consistent quality.
2.2 Managing Changing Priorities
Managing change is what agile is designed for — the ability to quickly and coherently respond to changing business requirements. This is in contrast to the classic waterfall project, where all requirements are fully defined prior to development. Once development is underway, it is expected that requirements won’t change. The following agile practices supports managing change as a regular event:
Planning at the beginning of each iteration. In Scrum this is called Sprint Planning. Top priority items are taken from the product backlog and planned for the next iteration. This means that business can change its priorities all the way up to the day of planning.
Regular reviews and demos with project stakeholders provide an opportunity for quick feedback and course correction if necessary. In Scrum this is called the Sprint Review and occurs at the end of each Sprint.
Daily stand-ups (or Scrum) – this common agile practice gives the team the ability to address any immediate issue and plan accordingly.
2.3 Increase Productivity
An increase in productivity means delivering more business value in a given amount of time. There are a few agile practices that supports this goal. For example:
One of the agile principles is “ Simplicity – the art of maximizing the amount of work not done – is essential”. Getting rid of waste, or work not required, will boost productivity.
Another agile principle is “agile processes promote sustainable development.” On the surface this agile principle may not appear to support increase productivity, but it does in several ways:
- Delivering higher-quality software, thus reducing time spent on fixing defects.
- Increasing team morale, thus maintaining team stability. Stable teams tend to become more efficient over time.
- Building in slack time in a schedule gives creative knowledge workers the time to create new and better ways to solve problems. Teams that constantly worry about the stress of delivering more work don’t have the time to reflect on how to do their job better, or learn new skills.
2.4 Improve business/IT alignment
A key element of a successful agile adoption is business engagement, to ensure that business needs are being met. Here are some key agile practices that support business/IT alignment:
The role of Product Owner in Scrum, or the “on-site customer” in XP, is a must-have for agile projects. This person owns the ROI, and has to be highly engaged and available to the team to define and prioritize the work. If there is no Product Owner or customer representative then it will be difficult to deliver business value or respond to changing business needs.
Regular demos to stakeholders are an important part of the agile cadence. In Scrum these are called Sprint Reviews. It is an opportunity for stakeholders to give feedback on what is being delivered at the end of each iteration, and to engage with the agile team on priorities for upcoming iterations.
Ultimately, successful agile adoption depends on agile initiatives meeting the goals of the organization. When there is a good understanding of how agile values, principles, and practices (i.e. the agile mindset) supports meeting these goals, then there will be a higher likelihood of success.