15 Useful Pacts for Agile Teams: An Agile Team Creed

The Agile Manifesto values “Individuals and Interactions” over “Process and Tools.”  I suspect it was no accident that this was listed first.  Lack of communication, miscommunication, or the mistaken presumption that communication has occurred, are the root cause of many problems.  Yet, we still focus much discussion on the process and tools.

  • When and how do you conduct a certain Scrum ceremony?
  • Are you practicing pure Scrum?
  • Which agile tools do you use and why?
  • How do you use the tool?
  • What agile metrics are you using and how?
  • What best practices exist?
  • And lots more concerns and questions about how to “do” process…

However, most all change transformations to “be” agile struggle with organizational culture and many organizations and teams continue to fail to reach their full potential because of issues related to “individuals and interactions.”

Teams are the heartbeat of agile development.  It’s the people that produce business success.  Even when the organizational culture embraces agile values, the teams must also address their individuals and healthy interactions among them to maximize value.  This takes time and effort to mature.  I find we mistakenly assume that since people know each other already and even “behave” nicely, they think they can skip over the team-building activities.

Simply gathering individuals together and assigning them the label of “team” does not make a team.  Each team is comprised of unique personalities and thus there is no cookie-cutter best answer for every team.  Each team must find its own way and navigate the uniqueness of each individual to determine the best way to handle interactions that work for their team dynamic.  There should be “pacts” that everyone on the team agrees to.  If there are dysfunctions (egos, prima donnas, passive aggressive behavior, apathy, poor listening skills, a presumed hierarchy, and so on), then the challenge is an order of magnitude that’s much more difficult.  Each team is a unique, dynamic system, subject to changing moods and their environment.

Sadly, some agile teams never evolve beyond a collection of individuals who meet together at the prescribed Scrum ceremonies and then return to work independently with a focus on their individual tasks only.  Maybe the ability to track their work has improved, but they have failed to recognize and harness the true potential that comes from working as a high-performing team.  Perhaps you have seen teams who are full of energy and so you recognize the power of teams?  So, why do some teams never get there?  There are multiple factors that influence agile and Scrum teams.

Let’s assume that the organization’s leadership values the power of teams and has a supportive culture and vision in play.  So what can be done within the team to ensure that it sets a solid foundation for growth and success?

During the team forming stage, it is important for the team members to openly discuss behaviors and expectations.  There is great value in recording those discussions as a reminder to the members when they do encounter problems.  But, they need to dive deeply into what each member truly believes and feels.  Because what you believe and how you feel directly determines how you will behave.  These team discussions must go beyond the process-mechanics agreements such as what time to meet.  They need to communicate something more of an “agile team creed” or list of pacts they make with one another. Team members must be comfortable sharing their fears and concerns.

Having an agile team creed is a great starting point for deep team discussions to root out true beliefs.  It captures cultural expectations and behaviors for the team which I believe lay the foundation for a great agile team.  Here is my list of 15 useful pacts agile teams can make.  I call it the Agile Team Creed.

Agile Team Creed

Has your team had these deep conservations about what they believe?  Would they agree with these items as part of their Agile Team Creed?  If not, why?  Perhaps, it reveals a cultural issue that needs attention.

Posted in Agile Adoption, Agile Leadership, Agile Management, Agile Methodologies, Agile Teams, Scrum Methodology | Leave a comment

Super-Sized Agile

Guest post by Bob Schatz of Agile Infusion, LLC

agile-infusion-bob-schatzThe interest in expanding agile development practices is growing at an increasingly faster rate. The good news is that this indicates that companies are seeing positive results in their initial experiences on projects and are looking to further the expansion, even beyond product development. The challenge is recognizing that these early successes required overcoming many obstacles and shifting the mindset of a number of people. And that these things get exponentially harder as you introduce change across the enterprise.

The pressure is also put on consultants, trainers, authors, speakers, agile software tool vendors, and coaches to codify and simplify models to reduce the strain from employing agility at scale or “super-sized agile). When success happens, everyone wants to share the experience, but they often focus on showing the model that worked for them in a specific case. Since the structures are simple by design, this creates a feeling that it must be relatively painless to just replicate the experience in other parts of the company, and then to other companies.

This is similar to what we’ve seen in the past with the basic Scrum process, Lean/Six Sigma, the Toyota Production System and just about any process improvement strategy that has a significant success story to tell. As a result, there has been a flood in the community of scaled agile methods that are all too similar to be called different. Arguments ensue on a daily basis; thought leaders pit their methods against the others trying to prove why they have the right answer. A slew of marketing professionals try to position each method as the better answer in hope of attracting a “big fish” company that will tout how successful the method made them. Right now, we have no less than six scaled agile methods actively being marketed, not to mention the hybrids that companies are presenting in conferences, articles and such. And the methods just keep coming! Ultimately, success will require:

  • Identifying the problem you are trying to solve
  • Understanding your current organization and its ability to satisfy consumers
  • Identifying the gaps
  • Designing an organization and process
  • Growing your leaders at all levels
  • Execution and relentless continuous improvement

In order to bring us back to the ground, I would like to tell a couple of my own stories which might help you and your organization focus on keeping things simple and overcoming the struggles that all organizations will eventually face in order to instill a culture of continuous improvement and process innovation. These will be critical to serving your customers better than anyone else can.

Back to the Future

My first story is from what seems not too long ago, but I guess that’s what all of us “old-timers” say.  I came into the software profession as a programmer in 1984. I was hired by GE in Valley Forge, PA in the start of my senior year of college when defense contractors were building up at an incredible pace.  I was really looking forward to seeing how the little projects we were doing at school would apply to working on a massive Department of Defense project. And just to be honest, a lot of my school projects involved punch cards. So, the first scaling problem I had was keeping a huge deck of cards in the right order!

The first project I was assigned to at GE was a massive system involving hardware, space vehicles, communications, ground stations, and a host of other components and challenges that made my head spin. The system involved thousands of people across multiple contractors and government agencies all working together to solve a huge problem. It was even more complicated by the fact that this was a classified system where we had to deal with compartmentalization and people with different need-to-know levels that restricted with whom you could collaborate.  The project management was mostly visual techniques and we relied heavily on interface control documents, which let us know the inputs and outputs for our piece of the puzzle. (In reality, those documents were not entirely accurate, coordinated, or followed, which caused more than a few defects later in the project).

We all relied heavily on each other to communicate from one component or process to the next. System integrators tried to keep an eye on all of the parts to ensure a smooth system-wide deployment. These projects went on for years. We employed what we now know as the waterfall development model, but at the time we just referred to it as MIL-STD version 2167.  Now, I’m not claiming that these were smooth projects. They were terrible and required massive amounts of overtime (which luckily we were paid for), rework, and heroics of some of us to pull it off. These were much different times, but looking back, we did what always worked, and used common sense and a will not to fail. We were motivated to serve our nation’s best interests and we were young, enjoying cashing in those big overtime checks. Organizing ourselves was less of  an issue, knowing that we had to solve important problems and everyone was focused on success.

For my 12 years there, the projects got bigger and more complex. We kept using the same organization techniques because they worked for us in those circumstances.  Every project required a level of heroics at the end, which nobody would tolerate today. These were different times. Today’s software development environment requires faster speed, much higher quality, and the ability to adapt to a much higher rate of change. My point here is that we didn’t need a model to tell us what to do and, to my knowledge, there was never a Scaled Waterfall Model.

A Burning Platform

Fast-forward through a number of great experiences, including a very successful start-up where I really learned the value of agility in its purest sense before “agile development” was a term. At the end of 2001, I wound up as the vice president of development at Primavera Systems. Now part of Oracle, Primavera makes enterprise portfolio, program, and project management software. This was where we used Scrum staring in early 2003 in an organization with almost 150 people — that became one of the first, and certainly well-publicized agile success stories.

We started off with the goal to improve our lives, our products, and our relationships with other groups in the company. We had serious issues with our product and process. More importantly, our people were suffering. Nothing I tried in all of my leadership experience to date had worked to my satisfaction in my first year there, so it was time to radically re-tool.  Scrum was just a leap-of-faith decision to attempt to save us.

Our challenges began with figuring out how to create Scrum teams. We wound up with about 20 of them all working on a single, large enterprise product. We ran into a lot of issues with builds and people stepping on each other, so we innovated. We set our focus on stopping the branch/merge environment and forced ourselves into a single trunk, so everyone was now responsible.  We had discussions about how to coordinate dependencies, coordinate development of feature sets involving multiple teams, and how to deal with obstacles that affect many teams. As with everything we didn’t have an answer for, we designed experiments and tried them. This led us to create the idea of having a representative from each team form another Daily Scrum after each team conducted their own to coordinate and deal with cross-team topics. This eventually became known as the Scrum of Scrums. It also led to solving the issue of having 10 product owners learning to coordinate their decision-making by establishing a chief product owner role.

We created the idea of an integration Scrum team focused on testing integrations with other products in our portfolio, as well as third-party integrations. They also did continuous performance testing. We carved out fixed days/times for functional meetings so that directors of development, testing, documentation, etc. could spend two to three hours developing their people and their disciplines. We had teams who organized around certain product areas, architecture, and database development, helping to keep everything coordinated. We kept working on the process to improve and expand it.

Once we had a good handle on our own work, we had all other organizations participate in Sprint Reviews so they could get access to the product being developed. We brought in end users from the very start and just kept getting more and more of them to participate, which really helped us to build a better product. They became increasingly engaged in helping us manage our portfolio and product backlogs.  As we moved forward, we dealt with other challenges like having multiple chief product owners, all with their own products wanting to use the same Scrum teams, and learning to manage the flow of work.  Later, we encountered  the challenges of distributed development and forming Scrum teams in India and the Ukraine.

Through it all, we just kept doing the hard work of solving problems and not looking for the silver bullet as Ken Schwaber had taught us so well. The message is clear; agile development practices are simple by design; implementing them is hard. It requires people who want to improve their circumstances. They want to serve their customers better than everyone else. They are willing to use their smarts to design experiments that will help them get there. And they are willing to fail sometimes, but learn quickly.

So, Now What Do We Do?

The answers to large-scale agility do not lie in a book, or a set of slides, or a poster. Every project that has more than one team is a project at scale, and every environment is different. The answers will emerge when people are willing to put in the work. There are no shortcuts; seeking shortcuts will only result in change initiatives that will not survive the test of time. Stories like these can help spark ideas, but they are not to be followed like a recipe. Doing so only sets us up to repeat history. So, the first question is not which model to follow, its asking yourselves “What problem are we trying to solve?”

Posted in Agile Adoption, Agile Development, Agile Portfolio Management, Agile Teams, Agile Tools, Distributed Agile, Scrum Development | Leave a comment

Why is it Called an Agile Transformation?

Guest post by Charlie Rudd of SolutionsIQ

We’re not in Kansas anymore.

Most organizational change initiatives are not called transformations. So how come agile change initiatives are? To answer this question, let’s first review some examples of organizational change as well as the impact they have on the people in the organization.

 

charlie-rudd-solutionsiq-image

 

Note in the above table how the magnitude of change deepens as you move from the top to the bottom of the table. At the top of the table, the change has little impact on the day-to-day work of most individuals. However, at the bottom, the impact of change can be quite profound. For example, changing the corporate culture uproots deeply embedded behavior and necessarily changes long-standing beliefs and assumptions.

Working with this principle, we can identify three levels of organization change magnitude:

Superficial org change

This type of org change has little impact on your day-to-day responsibilities and activities. Many corporate re-orgs are actually superficial. For example, your company may hire a new VP, but that doesn’t necessarily affect the project you’re working on, the work you perform on it, or the people you work with.

Significant org change

This type of org change has a greater impact on you. Your job or your work environment is affected, but usually not your role or job description. For example, some work procedures may change, and you may receive training or new software tools as a result. You may even have to join a new team or someone new joins your team. Perhaps you have to move to an office in a different building. Whatever the case, when your organization undergoes a significant org change, you are definitely affected even if the effect is rather minimal.

Transformational org change

Often, after a transformational org change, you have a new role that you have never performed before. Your job responsibilities change radically. So do your supervisors and their responsibilities. You have to approach your work in an entirely novel way, learning completely new skills, and often a new vocabulary. The unwritten rules that used to guide how you act and what you do no longer apply. Your work world is completely new. It’s surprising. It’s refreshing. It’s strange.

Let’s now consider where agile transformation fits within this org change magnitude framework:

Agile org change

In an agile transformation initiative, some of the change is superficial – some more significant – but when successful, the bulk is transformational. Learning new practices and tools are needed, but not sufficient for lasting success. Change must go deeper, in many cases down to the roots of corporate values, and what had been unquestioned management principles. It must encompass a new way of thinking about work and your place in this new world. Long-standing assumptions and unwritten rules go out the window as you discover new ways to work together with your colleagues, every day. This is why it’s called an agile transformation:  you, your job, your responsibilities, your management, and your organization are transformed into something new.

So are we in Kansas anymore? In a word:  nope. We’re not in Kansas. Agile transforms your world. It’s surprising. It’s refreshing. It’s strange. Whatever you think agile may be, there’s one thing it’s not:  business as usual.

Posted in Agile Adoption, Agile Management, Scaling Agile | 2 Comments

So You Want to Scale Your Agile?

Guest post by AgileBill Krebs of Agile Dimensions

Some teams – such as sustaining engineering teams – are fine with Kanban. This method shows work on a taskboard as it progresses from waiting, to doing, to done, with an eye toward cycle time and focusing on a few things at once.

Some teams are fine with traditional Project Management Body of Knowledge (PMBOK – from the PMI) – as in special client engagements.  This covers key project aspects such as cost, procurement, communications, and may use a Gantt chart to plan jobs of known but varying sizes.  Unlike most of our agile projects, this will assume there is little likelihood of change.

Some teams are fine with Scrum development.  Two-week iterations and sprints give vital visibility into progress, and also windows for change.  Teams learn empirically and use these iteration windows to tune and adjust their product and procedures.  Extreme Programming (XP) plans in a similar fashion, but adds some technical practice to build quality in.

These teams often have nine or fewer people, with three to six months for work.  But what if the project or product you deliver has 40 people?  100 people? 300 people?

Projects like these would require scaling up your agile.  Authors such as Jutta Eckstein, Scott Ambler, Kenny Rubin, and Dean Leffingwell have all described ways to do this.

Using such concepts in practice with dozens of teams has shown six key areas:

1)  Roll-out – does management and the teams know agile at scale is different?  Are they committed to doing it, and have they had some training on multi-team agile?   Do you have someone prepared to program manage a team of teams?

2)  Common language – one team can use whatever terms they wish.  But when team of teams (aka, Scrum of Scrums) forms, it quickly becomes a mess where some say ‘Feature’ and some say ‘Epic.’  Pick a scaled agile methodology and vocabulary, and make that your organization’s common language.

3)  Features – it helps organize larger projects to use the ‘parent’ of a story.  Let’s call this a ‘Feature’ (like Dean Leffingwell’s Scaled Agile Framework® or SAFe™).  While we still use small Stories, it becomes more important to plan ahead using larger Features so other teams can know when to depend on our output.  This also helps stakeholders gain a picture of our product even as the number of Stories multiples as the team grows in size.

4)  Align the business – with larger projects, it becomes even more important for business-facing parts of your organization to connect with your scaled agile process. Planning at higher levels such as portfolio (multiple products) and program (multiple teams) becomes more integral to how we work.  But working with our market experts is harder if they do not understand our terminology and approaches to delivering at scale.  Other areas such as accounting and your project management office may need to understand your scaled approach as well.

5)  Kick off each release – spend a little more time before each release to look for dependencies between high-level features.  Let teams know what’s coming, and have them discuss how they will deliver together.

6)  More than a dozen teams – it makes sense to forge four or even 10 teams into a group that delivers a product.  But if you product requires more than a dozen teams, that will be big enough to demand another sub organization with its own program manager.

Agile development has been used in many projects, large and small.  Keeping these six factors in mind will help with your enterprise-strength projects. Taskboards may be sufficient with smaller projects, but larger projects benefit from tools designed to see things at more levels – portfolio, program, and team.

What steps can your project take to work smoothly between teams? 

agilebill“AgileBill” Krebs has over 20 years of programming, performance, project management, and training in the IT industry at 5 IBM labs, banking, telecom, and healthcare.  He has used agile since 2001, and taught it to over 2,000 people worldwide. He has presented at agile conferences, IBM Research, and conferences on education. Bill’s certifications and groups include SPC, PMI-ACP, CSP, ICE-AC, and others.  He hosts the Distributed Agile Study Group and is a member of ALN, the Scrum and Agile Alliances, ACM, AERA, PMI, and more. He is pursuing a graduate degree in education technology, while working as an enterprise agile coach in the healthcare IT industry.

Scaled Agile Framework is a registered trademark and SAFe is a trademark of Scaled Agile, Inc.

 

Posted in Agile Development, Agile Methodologies, Agile Portfolio Management, Agile Project Management, Agile Teams, Enterprise Agile, Kanban, Scrum Development, Scrum Methodology | Leave a comment

Scaling Agile Your Way: Sweet Spots, Challenge and Unfit Zones for SAFe and MAXOS (Part 3 of 4)

In Part 1 of this four-part series, I explained why a cookie-cutter approach will not work as you undertake large-scale agile initiatives.  Each agile project developing a product or a solution has a unique context: assumptions, situation, team members and their skill sets, organizational structure, management understanding and support, maturity of practices, challenges, culture, etc.

In Part 1, I proposed a fairly comprehensive list of 25 scaling agile parameters classified into six scaling aspects:  Teams, Customers/Users, Agile Methods and Environments, Product/Solution, Complexity, and Value Chain (see Tables 1-4 of Part 1 of this blog series).  Each scaling agile parameter can assume one or more values from a range of values.   Each organization or a large-scale project is likely to select a different combination of these 25 scaling agile parameters that are relevant; moreover, the value or range of values for each scaling agile parameter for a project or an organization is likely to be unique.  However, “Scaling Agile Your Way” does not imply a license to optimize at the subsystem levels (teams or programs) at the expense of overall system-level optimization (portfolios and enterprise).  Systems thinking is important for Scaling Agile Your Way.

In Part 1, I presented a brief overview of various popular Agile and Lean scaling frameworks: Scaled Agile Framework® (SAFe), LeSS, DAD and MAXOS.  Although there are differences among SAFe, LeSS and DAD, they all are very different from MAXOS.   In Part 2, I compared and contrasted SAFe vs. MAXOS in depth.  SAFe and MAXOS represent radically different approaches to scaling agile. Tables 5-10 of Part 2 presented the differences between SAFe and MAXOS from the perspective of 25 scaling agile parameters covered in Tables 1-4 of Part 1.

Today, I will focus on the Sweet Spot, Challenge Zone and Unfit zone for SAFe and MAXOS:

Sweet Spot:

  • Indicates a good match between a scaling agile framework and a scaling agile parameter with a specific choice or range of choices selected for the parameter
  • Implementation becomes easier, more efficient and effective

Challenge Zone:

  • Indicates a challenging match between a framework and a scaling agile parameter with a specific choice or range of choices selected for the parameter
  • Requires more implementation effort compared to the Sweet Spot

Unfit Zone:

  • Indicates a poor match between a framework and a scaling agile parameter with a specific choice or range of choices for the parameter
  • Poor match could happen for one of two reasons:  (1) the parameter value chosen is not applicable, or (2) the parameter value chosen will not work well

Figure 1 illustrates the Sweet Spot, Challenge Zone and Unfit Zone for SAFe, while Figure 2 presents similar information for MAXOS.  These are organized by the six scaling aspects mentioned above.  You will see four arrows in each Figure showing our recommendation for taking your large-scale agile projects closer to the Sweet Spot over a period of time.  I urge you to carefully review all of the information presented in Figures 1 and 2.  There is a lot of information, and it will take time to fully understand.  You may find it helpful to discuss with other agilists within your company.

Figure1

Legend_Part3
Figure 1: Sweet Spot, Challenge Zone and Unfit Zone for SAFe

Figure2

Legend_Part3
Figure 2: Sweet Spot, Challenge Zone and Unfit Zone for MAXOS

 From the information in Figures 1 and 2, it is clear that SAFe and MAXOS offer mostly distinct Sweet Spots, Challenge Zones and Unfit Zones, although occasionally there may be some overlap.  For example:

  • As shown in Figure 1, cross-functional, self-organized teams with co-located or close-by time zoned team members working under low to moderate governance structure offer a Sweet Spot for SAFe. But in Figure 2, self-organized, developer-centric (not cross-functional) teams of co-located members with minimal governance overhead offer a Sweet Spot for MAXOS.
  • In Figure 1, emerging user needs that must be discovered with sustained effort represent a Challenge Zone for SAFe; in Figure 2, the same scaling agile parameter value offers a Sweet Spot for MAXOS.
  • In Figure 1, low to moderate product modularity represents a Challenge Zone for SAFe, while Figure 2 shows that low modularity (tight integration of all code) creates an Unfit Zone for MAXOS.  On the other hand, a high degree of modularity in the product/solution architecture represents a Sweet Spot for both SAFe and MAXOS.
  • In Figure 2, heavy and rigid governance, or heavy/life-critical regulatory regime represent an Unfit Zone for MAXOS. But in Figure 1, the same scaling parameter values offer a Challenge Zone for SAFe.
  • In both of these, we see that, “Tightly coupled hardware product with embedded software and services (ex. appliances, cars, medical devices, smartphones, wearable computers, military gear, industrial equipment)” represent an Unfit Zone for both SAFe as well as MAXOS.

Get As Close to the Sweet Spot As Possible

If you decide to use SAFe in your enterprise (at least for some programs and portfolios), ideally you should try to get as close to the SAFe Sweet Spot as possible.  I have similar advice if you decide to use MAXOS (get as close to the MAXOS Sweet Spot as possible).  It is quite possible that your entire enterprise is not close to the Sweet Spot when you are just beginning your scaling agile transformation effort.  In that situation, I suggest starting with a scaling agile pilot program of 5 to 10 teams; after their initial education on SAFe (or MAXOS) is over, have this pilot program start as close to the Sweet Spot as possible.  This may require changes in some of your historical processes and practices, and development of SAFe (or MAXOS) with clear understanding and support for from your senior management.

For example, a pilot for SAFe may need to choose a relatively moderate domain complexity project, fairly modular architecture to minimize inter-team dependencies, co-located team members for most teams, a good deal of test automation and continuous integration (with prior training), a set of strong servant-leader ScrumMasters for each team, low to moderate governance overhead, low to moderate regulatory compliance regime, low to moderate impact of defects, etc.  See the Sweet Spot for SAFe in Figure 1.  If the pilot program teams are not close to the Sweet Spot yet, senior management will need to help them get there as the starting point for the pilot to make the scaling agile journey less painful.  With the experience of one release cycle underway, more pilot programs can be started close to the Sweet Spot; in fact, while the first pilot is going on, one to four more pilot programs can be identified and necessary effort expended to bring them close to the Sweet Spot as a starting point for their upcoming SAFe (or MAXOS) pilots.

Dealing With the Unfit Zone

The other extreme of the Sweet Spot is, of course, the Unfit Zone.  If a pilot team finds themselves in the Unfit Zone for at least one scaling agile aspect, the pilot will very likely fail.  For example, if a SAFe pilot program must use contributions from the open source community, or a MAXOS pilot program must operate under a rigid or heavy governance structure, or work under a life-critical regulatory regime, it will most likely fail.  Senior management must either take action to remove the issues creating the Unfit Zone, or select a different pilot program that does not find put the pilot in the Unfit Zone for any of the six scaling aspects.

Your Journey to the Sweet Spot is Your Tailored Journey

Your transition of your pilot program to the SAFe (or MAXOS) Sweet Spot will be your own customized plan and journey tailored to your situation.  You need to consider where these pilot teams are now, the gap between their current status and the Sweet Spot, and the effort and time needed to bring them closer to the Sweet Spot.  This effort will be dependent on each team’s situation, and is a very important aspect of “Scaling Agile Your Way.”  How do you take a pilot program close to the Sweet Spot is going to be your own unique journey and cannot be copied from a recipe book.  If a pilot program or a specific team within that program cannot reach the Sweet spot across all six scaling aspects, maybe it will come close to the Sweet Spot for four out of six scaling aspects, and stay in the Challenge Zone for the remaining two.  When a pilot program is in the Challenge Zone with respect a scaling aspect, it does not mean that the pilot program cannot start or proceed; but it does mean that you need to be prepared to spend more effort and overcome difficult challenges if you are going to operate in the Challenge Zone.

For example, if a pilot program has one or more teams with their members in different locations with widely different time zones, the SAFe Release Train Planning (two-day event required by SAFe) may involve a lot of complicated logistics and travel time/expenses for remote people, for which senior management support might be hard to come by (after all, “this is a pilot” is likely to be the argument).  If the pilot needs to operate under a traditional, hierarchical and rigid structure, it may create many organization impediments, complicating the challenges for the pilot program.

As shown in both Figures 1 and 2, your transition plan is to move as close to the Sweet Spot (the inner most rectangle area) as possible from the directions of Unfit Zone and Challenge Zone. This is illustrated by four broad arrows pointing toward the innermost rectangle in Figure 1 for SAFe and in Figure 2 for MAXOS.  If you find that your large-scale agile initiative (a program or a portfolio) is in the Unfit or Challenge Zone, you need to find the reason(s). The culprit is likely one of two things:

1.  Internal to your own organization (its history, culture, current practices, etc.).  This is an opportunity for your senior management to remove or mitigate those reasons and demonstrate its understanding and commitment to the success of scaling agile.

2.  Rooted in the market and business environment of your organization.  These reasons cannot be removed by senior management (if you want to stay in the business).  You will need to replace or augment the scaling agile framework practices with your own custom practices and retain the practices from the framework that are still applicable.

Table 11 below captures the Unfit Zone and Challenge Zone in its two rows, and the above two classes of reasons in its two columns.  The cells in this table illustrate specific examples of an action plan.

Table 11: Reasons and Actions for Unfit and Challenge Zonewith Examples

Table11a

The transition from Unfit or Challenge Zone to Sweet Spot will require planned, disciplined and concerted effort — and a good understanding and true commitment from your senior management.  This journey will be uniquely yours, and cannot be copied from a cookbook.  Over time, you will find that you are moving closer and closer to the Sweet Spot, but still have few areas in the Challenge Zone.

Customization Needs and Opportunities for Implementing Your Scaling Agile Framework

In addition to your unique and tailored journey toward the Sweet Spot of your scaling agile framework, a very important aspect of Scaling Agile Your Way is that each team, program or portfolio may need to implement key aspects of its framework in unique and customized ways.  It seems that the Scrum at Scale (meta)-framework under development by Jeff Sutherland and Alex Brown can be used to implement a variety of process modules of SAFe in customized ways.  Customization needs and opportunities for the MAXOS framework will come mostly in the context of implementing its advanced engineering practices of code contribution, automated testing, continuous integration, feature switches, continuous delivery, and making use of cloud computing facilities, etc.  I will elaborate on this topic in Part 4 of this series.

Are you about to start your scaling agile journey?  If so, do you have one or few pilot programs consisting of 5 to 10 teams in mind?  How do you feel getting them started closer to the Sweet Spot of SAFe, MAXOS or any other framework of your choice (such as LeSS or DAD)?   Have you run into the Unfit Zone for any scaling aspects?  I would love to hear from you either here or by email (Satish.Thatte@VersionOne.com) or on Twitter @smthatte.

Part 1: Scaling Agile Your Way: Agile Scaling Aspects and Context Matter Greatly

Part 2: Scaling Agile Your Way: SAFe™ vs. MAXOS

Part 4: Scaling Agile Your Way: How to develop and implement your custom approach

Posted in Agile Benefits, Agile Coaching, Agile Management, Agile Methodologies, Agile Portfolio Management, Agile Project Management, Agile Teams, Distributed Agile, Enterprise Agile, Scaling Agile, Scrum Methodology | Leave a comment

Scaling Agile Your Way: SAFe vs. MAXOS (Part 2 of 4)

In Part 1 of this four-part blog series, I explained why a cookie-cutter approach will not work as you undertake large-scale agile initiatives.  Each agile project developing a product or a solution has a unique context:  assumptions, situation, team members and their skill sets, organizational structure, management understanding and support, maturity of practices, challenges, culture, etc.

In Part 1, I proposed a fairly comprehensive list of 25 scaling agile parameters classified into six scaling aspects:

1.  Teams
2.  Customers/Users
3.  Agile Methods and Environments
4.  Product/Solution
5.  Complexity
6.  Value Chain (see Tables 1 through 4 of Part 1 of this blog series)

Each scaling agile parameter can assume one or more values from a range of values.  This comprehensive (but by no means, complete or exhaustive) list of 25 scaling agile parameters suggests that the agile scaling space is complex and rich with many choices.  Each organization or large-scale project is likely to select a different combination of these 25 scaling agile parameters that are relevant; moreover, the value or range of values for each scaling agile parameter for a project or an organization is likely to be unique.  However, in Part 1, I also clarified that “Scaling Agile Your Way” does not imply a license to optimize at the subsystem levels (teams or programs) at the expense of overall system-level optimization (portfolios and enterprise).  Systems thinking is important for Scaling Agile Your Way.

In Part 1, I presented a brief overview of various popular Agile and Lean scaling frameworks: Scaled Agile Framework® (SAFe™), LeSS, DAD and MAXOS.  Although there are differences among SAFe, LeSS and DAD, they all are radically different from MAXOS.  In this part of the series, I will compare and contrast SAFe vs. MAXOS in some depth.

Briefly, here are the key highlights of SAFe.  Details can be found at Scaled Agile Framework:

  • SAFe requires a “Portfolio, Program and Teams” hierarchy for a large-scale agile project.
  • Each team must be a cross-functional Scrum team and may follow many XP practices.
  • Epics at portfolio levels are managed as a Lean/Kanban flow.  Epics are broken down into features that can be completed in a single release cycle at the program level; each feature is broken down into stories that can be completed in a single sprint at the team level.
  • All teams in a release train of a program must follow the same lock-step sprint cadence (typically two weeks).
  • Release train planning requires all team members (typically up to 150) from all teams in a program to hold two-day-long release planning meetings in person, which entails a substantial effort and complex logistics.
  • Release cycles are typically eight to 12 weeks long.
  • Software is developed on sprint cadence, and released on demand (but cannot be released faster than the sprint cadence).
  • Considerable time and effort is spent in various ceremonies:  sprint planning, sprint review and sprint retrospectives, release train planning across multiple teams, release review and release retrospectives, etc.

Briefly, here are the highlights of MAXOS.  Details can be found in Andy Singleton’s Agile 2014 presentation.

  • MAXOS is the scaling approach for “Continuous Agile.”  Continuous Agile combines Kanban Agile task management with continuous delivery code management. 
  • MAXOS requires a number of (almost) independent service teams.
  • Services have well-defined APIs, are loosely coupled, and have minimal dependencies among them.
  • Each team operates with Lean flow.  Applications are rapidly composed of a group or a network of services.
  • Each team is developer-centric (not cross-functional) and highly empowered.
  • Code is continually integrated in a single code base across all teams.
  • Code is continually tested with automated tests (unit, acceptance, regression, etc.) by firing off as many virtual machines as needed in a cloud-based environment.
  • Any dependency issues across teams are immediately resolved via rapid team-to-team communication.  For rapid team-to-team or member-to-member communication, tool support is essential. VersionOne provides excellent communication and collaboration among team members.
  • The typical ratio of developers to testers tends to be 10:1, as teams are developer-centric and developers do most automated testing.   There are no separate QA teams.  QA testers are called as needed for their expertise by developer-centric teams.
  • Each empowered, developer-centric team decides when to release its code (not decided by QA testers or product managers!).  MAXOS claims that this policy rationally aligns the interests of developers with consequences of their release decision; poorly written, poorly reviewed, or inadequately tested code may mean “no weekends” or “No Friday evening beer” for developers!
  • All features or stories have switches (togglers) that the product owner (called story owner) decides to turn on (unblock) or turn off (block) based on the market needs.
  • Code released in production is extensively supported by automated user feedback collection, measurements and analysis that result in actionable reports for product management.
  • Automated feedback from production environment is also used directly by developers to immediately fix problems.
  • Meeting time is minimized by “automating away” management meetings, and removing or reducing other Scrum ceremonies.  For example, sprint and release retrospectives are replaced by periodic “Happiness Surveys” and taking actions based on those surveys.

Because of these fundamental differences between SAFe and MAXOS, they represent radically different approaches to scaling agile. The contrast between SAFe and MAXOS is breathtaking, and its implications are worth understanding.  Tables 5-10 present the differences between SAFe and MAXOS from the perspective of 25 scaling agile parameters covered in Tables 1-4 of Part 1.

These six tables (Tables 5-10 below) follow a specific color legend described below:

B_Legend

Table5a

Table6a

Table7a

Table8a

Table9a

Table10a

Are your agile projects closer to the SAFe Sweet Spot or the MAXOS Sweet Spot? 

Or are your projects closer to the SAFe Challenge Zone or the MAXOS Challenge Zone?  Or are you in a situation where neither SAFe nor MAXOS will serve you unique agile scaling needs? If you are exploring the use of LeSS or DAD framework, I would encourage you to use the list of 25 scaling agile parameters to identify the Sweet Spot, Challenge Zone and Unfit Zone for LeSS or DAD (as I have done in Tables 5-10 for SAFe and MAXOS). Then determine if your projects are closer to the Sweet Spot or Challenge Zone of LeSS or DAD.

I would love to hear from you either in the Comments below, by email (Satish.Thatte@VersionOne.com), or on Twitter @smthatte.

Related posts:

Part 1: Scaling Agile Your Way: Agile Scaling Aspects and Context Matter Greatly

Part 3: Scaling Agile Your Way – Sweet Spot, Challenge Zone and Unfit Zone for SAFe and MAXOS

Part 4: Scaling Agile Your Way – How to develop and implement your custom approach

Posted in Agile Adoption, Agile Benefits, Agile Development, Agile Management, Agile Methodologies, Agile Portfolio Management, Agile Project Management, Agile Teams, Distributed Agile, Enterprise Agile, Lean, Scaling Agile, Scrum Development, Scrum Methodology | Leave a comment

Scaling Agile Your Way: Agile Scaling Aspects and Context Matter Greatly (Part 1 of 4)

Consider these five very different types of organizations:

1.  An organization with fairly hierarchical management structure, traditional Project/Program Management Office (PMO) trying to transition from traditional waterfall development to agile development.  Some teams have just a few months of experience with Scrum, and perhaps worked with few XP or Lean practices.  Budgets are done on an annual basis.  Senior management pays lip service to agile transformation and treats agile as a silver bullet.

2.  A government contractor is used to delivering projects on a fixed-price basis.  The government agency has now asked the contractor to use agile methods for large-scale agile projects.

3.  The CIO and CEO of an enterprise are strongly committed to agile-lean development and have given a top-down marching order to follow agile methods.  All teams have been ordered to follow a two-week iteration cadence, while members of some teams come from an offshore outsourcing vendor.

4.  A company has found that their main competitor will be Amazon.com.  The release cycle for most of its IT projects is six months, and they know that unless they drastically reduce this, Chapter 11 is not far away.

5.  A startup company realized that unless they validate their assumptions about who the real customers are, and what the real needs of real users are, they have no viable business.  They decide to follow the Lean Startup method by rapidly developing a series of Minimum Viable Products (MVPs) in rapid succession.  Even after the first release of the product, the company must stay ahead of competition and deal with rapid changes in market conditions.

With the vast diversity of organizations and their projects, a cookie-cutter approach (or prescriptive recipe for all types of projects and situations) will not work.  Each agile project developing a product or solution has a unique context: assumptions, situation, team members and their experience and skill sets, organizational structure, management’s understanding and support, maturity of practices, challenges, culture, etc.

No_to_straight_jacket_agile

Many agile development teams now have some experience of team-level agile practices using Scrum, XP, Lean, Kanban or Scrumban frameworks.  Some of these organizations have experience with Scrum of Scrums (that is, two to as many as nine Scrum teams working together on a product or solution). These teams and their organizations are now setting their horizons to undertake large-scale agile projects where several (10 to 1,000) teams must collaborate to implement the common vision of a product or a solution.

In the last few years, there has been increasing interest in scaling agile-lean methods beyond individual teams or Scrum of Scrums to programs and portfolios of teams, as well as being able to compose new applications by stitching together a set of services developed by independent teams.  The recent Agile 2014 conference had numerous presentations on the topic of scaling agile.  I attended as many of them as my schedule allowed, and caught much of the rest as recorded sessions.

Many of these sessions raised the issue of ‘which scaling agile framework is best?’ I came away thinking that every large-scale agile project creates a unique situation. To tackle this question, there are really two broad approaches you can take to select the right agile-lean process for your project:

APPROACH #1: Select a well-known, scalable agile framework listed below.

A. Scaled Agile® Framework (SAFe™) by Dean Leffingwell and his associates at Scaled Agile Inc.
B. Large-Scale Scrum (LeSS) by Larman and Vodde
C. Disciplined Agile Delivery (DAD) and Agility at Scale by Scott Ambler and his associates
D. Matrix of Services (MAXOS) by Andy Singleton

If necessary, extend or adapt or customize the framework to suit your unique needs. As you gain experience, inspect and adapt for ongoing refinements and further customization. “Scaling Agile Your Way” does not mean that each new large-scale agile project must develop its own agile processes from scratch.

APPROACH #2:  Develop a customized approach from scratch.

Or, if your project has truly unique needs that cannot be satisfied by any available framework (such as SAFe, LeSS, DAD, MAXOS) even after customization of the framework, you may need to develop a set of new processes from scratch customized to your unique needs, and then sustain and maintain those processes.

In many organizations, not many in-house people have this kind of expertise that would actually work.  Moreover, this approach would be expensive and may not be cost-effective.  As such, this approach to large-scale agile projects should not be undertaken on the ground of ideological purity, but should be based on solid business reasons.

It is important to state what “Scaling Agile Your Way” does not mean.  It does not mean that each team in a program is free to choose and optimize its own agile method, practices, cadence, release duration, metric and reports, etc., without any coordination with and consideration of other teams in the program.  If this were done, although each team may end up optimizing its own way, that may ignore what is good for the higher level program.  Similarly, optimizing at the program level without any regard to the higher portfolio or enterprise level is not “Scaling Agile Your Way”.   Those kinds of decisions (disregarding the system level optimizations and trying to optimize only at a subsystem level) might amount to “Agile my way or highway”, irrespective of Approach # 1 or # 2 described above.  Systems thinking is important for Scaling Agile Your Way.

This blog series is not a tutorial on or an in-depth review of SAFe, LeSS, DAD or MAXOS.  I will provide a brief overview of these frameworks for getting started.  I will then present a set of 25 scaling parameters (organized into 6 scaling aspects) that need to be considered to decide what scaling approach and methods are best suited for your specific situation, and what kind of customization will be needed.

SAFe: SAFe is a popular agile scaling framework for “enterprise-class,” large-scale agile projects.  It has great market momentum going for it, with extensive information available in the public domain, and training/certification programs from the Scaled Agile Academy and its partners.  SAFe is a proven and publically available framework for applying agile-lean practices at scale.  Many agile project lifecycle management tool vendors (such as VersionOne and Rally) support SAFe.  I will cover SAFe’s Sweet Spot, Challenge Zone and Unfit Zone, and give examples of how to customize SAFe for your situation in this blog series.

SAFe is often criticized, rather harshly and often unfairly, as being overly prescriptive and hence not suitable for many large-scale agile projects.  In some situations, SAFe is a good fit (Sweet Spot), while in some other situations, SAFe may be in a “Challenge Zone” where some effort (such as enhancement and customizations) will be needed to overcome those challenges.  But even with that effort, you may be better off using SAFe, compared to developing your own set of agile processes and practices from scratch.  However, in some situations, SAFe may be in an “Unfit Zone,” i.e., it is either not applicable or will not work well.  Full disclosure: I am a certified SAFe Program Consultant (SPC).

MAXOS: A relatively new agile-lean framework called MAXOS allows you to scale a particular type of agile methodology called “Continuous Agile,” where teams release working code several times in a day. In fact, after each change, the code becomes releasable shortly, thanks to automated testing, continuous integration, and developer-centric teams.  All teams continuously integrate their code into an enterprise-wide common code base, with a very large number of automated test sets running continuously in a cloud computing environment.  MAXOS is being used at many leading high-technology companies, such as Google, Amazon, Hubspot, and Edmunds.com.   MAXOS is particularly well-suited for large-scale Software-as-Service (SaaS) for consumer mass markets, and for lean startups (based on Eric Ries’ Lean Startup methodology).  MAXOS offers a radically different approach to scaling agile compared to SAFe.  MAXOS also has its own Sweet Spot, Challenge Zone and Unfit Zone, as I will explain in this blog series.  The Sweet Spot, Challenge Zone and Unfit Zone for SAFe and MAXOS are very different.  The contrast between SAFe and MAXOS is breathtaking.   If your competition has started to use MAXOS and you are still using SAFe, your competition couldn’t be happier!  On the other hand, if you insist on using MAXOS in situations where SAFe excels, you would be making a poor decision.  Many practices from MAXOS (such as test automation and continuous integration) can be incorporated within SAFe.

At present, MAXOS doesn’t seem to have formal training and certification programs.  I attended MAXOS presentation by Andy Singleton at the Agile 2014 conference, and have reviewed most of the public information about MAXOS, including the eBook on Continuous Agile method.

LeSS: LeSS is regular Scrum applied to large-scale development.  LeSS is developed by Larman and Vodde.  A key message of Scrum is to avoid a cookbook of defined process. Realize that each team and each product will have to inspect and adapt their own Scrum adoption, which will evolve sprint by sprint. Therefore, the suggestions offered by LeSS are no more than that—suggestions.

DAD: DAD is a process decision framework developed by Scott Ambler and his colleagues.  The DAD is a people-first, learning-oriented hybrid agile approach to IT solution delivery. It has a risk-value delivery lifecycle, is goal-driven, enterprise-aware, and scalable.  DAD leverages proven strategies from several sources (Scrum, Lean, XP, Kanban, SAFe, DevOps, Agile Unified Process or AgileUP, Agile Modeling, etc.), providing a decision framework to guide your adoption and tailoring them in a context-driven manner.

Although there are differences among SAFe, LeSS and DAD, those differences are dwarfed by their differences from MAXOS.  For example, while SAFe, LeSS and DAD are predicated on cross-functional teams with a number of meetings required, MAXOS advocates developer-centric, highly empowered teams (developers, not QA, decide to release!), and “management automation” to eliminate many meetings.  As LeSS and DAD are not as popular as SAFe at this time, I will not cover them further in this blog series.

You can use the Agile Scaling Knowledgebase (ASK) decision matrix to access a template for comparing SAFe, DAD, LeSS and other scaling agile frameworks.

SAFe and MAXOS cover a fairly large territory of vastly different types of large-scale agile projects.  Once you understand SAFe and MAXOS, and your own unique situation, you may be better off using one of those (with appropriate customizations as needed), rather than creating one from scratch and sustaining your own custom agile processes (an expensive and risky proposition).

There may be unusual situations where neither SAFe nor MAXOS may be a good fit for a large-scale agile project.  I will cover this topic in Part 3 of this series.  If you believe that your large-scale agile project has unique requirements that render both SAFe and MAXOS totally useless, and you have no choice but to create, maintain and sustain your own custom processes for your large-scale agile project, please let us know.  I would be very interested to know about your unique situation and what led you to prefer custom processes from scratch.

Customization approach:  Scrum at Scale (meta)-framework developed by Jeff Sutherland and Alex Brown starts with the basic premise that Scrum is an object-oriented framework.  Scrum at Scale framework is aimed at extending Scrum for large-scale agile projects, while retaining Scrum’s object-oriented architecture.  Scrum at Scale framework, along with its pattern library, are aimed at allowing agile projects to develop their own unique and customized methods for scaling Scrum to large-scale projects.  In Part 4 of this blog series, I will explain salient aspects of Scrum at Scale, and how its object-oriented approach may be used for customizing SAFe for your own unique needs.

Agile Scaling Aspects and Parameters:  Any large-scale agile project needs to consider a number of scaling parameters in order to decide which scaling framework would be most appropriate for its unique needs, or whether it needs a totally custom set of agile processes.  Table 1-4 shows a set of 25 scaling parameters, grouped into 6 scaling aspects:

1.  Teams

2.  Customers/Users

3.  Agile Methods and Environments

4.  Product/Solution

5.  Complexity

6.  Value Chain

The list is a fairly comprehensive, but by no means, exhaustive.  If some of the 25 parameters are not appropriate for your large-scale agile project, you need not consider those parameters.  If any scaling aspect or parameter is missing from the list, please let me know.  Each scaling parameter may take one more values from range of options. For example, “Number of teams” parameter associated with “Teams” scaling aspect has a value in the range of 10 to 1,000.  “Composition of teams” parameter associated with “Teams” scaling aspect can select a value in its range of options: Developer-Centric, Somewhat Cross-Functional with Guest Experts, or Fully Cross-Functional.  Multiple options can also be selected as long as they are not contradictory.  For “Composition of teams” parameter, only 1 out of 3 possible values can be selected.  On the other hand, for “Agile method of choice and required tool support” scaling parameter of “Agile Methods and Environment” scaling aspect (see Table 2), multiple choices are possible, such as Scrum, Scrumban, and Scrum+Lean.

Many of 25 scaling parameters are considered by ASK, DAD and Scrum at Scale frameworks.  Tables 1-4 use the following legend to indicate which scaling parameter is covered by ASK, DAD or Scrum at Scale.

  • A:  ASK
  • S: Scrum at Scale
  • D: DAD/Agility at Scale

Note that some of the 25 scaling parameters are not covered by any of these frameworks.  For example, “# 5. Composition of Teams: Fully Cross-Functional” scaling parameter is covered by all A (ASK), S (Scrum at Scale) and D (DAD); while “# 5. Composition of Teams: Developer-Centric” scaling parameter is not covered by ASK, Scrum at Scale or DAD.

Table1b

Table2b

Table3b

Table4

As you review the information in Tables 1-4, you will realize that the “scaling agile” space is complex and very rich with many choices.  Each organization or a large-scale project is likely to select a different combination of these scaling parameters as relevant; moreover, the value or range of values for each scaling parameter for a project or an organization is likely to be unique.

What agile-lean scaling approach are you considering: SAFe, LeSS, DAD, MAXOS, or something else?   What are your customization needs, and does your selected approach fit well with those needs?  I would love to hear from you either here or by email (Satish.Thatte@VersionOne.com). I’m also on Twitter@smthatte.

Part 2: Scaling Agile Your Way – SAFe vs. MAXOS

Part 3: Scaling Agile Your Way – Sweet Spot, Challenge Zone and Unfit Zone for SAFe and MAXOS

Part 4Scaling Agile Your Way – How to develop and implement your custom approach

Posted in Agile Adoption, Agile Management, Agile Methodologies, Agile Portfolio Management, Agile Project Management, Agile Teams, Distributed Agile, Enterprise Agile, Scaling Agile, Scrum Methodology | Leave a comment

7 Things I Validated in My First Month With VersionOne

What’s your lucky number? In June, I attended the Agile West BSC/ADC conference in Las Vegas and didn’t do so well at the roulette table; however, two months later on 7/21/14 (lucky 7s) I placed an even bigger bet; not on red, but on Pantone Color Number 216. It’s the signature color of VersionOne, the all-in-one agile project management tool and services provider.

After almost seven years of building up my agile acumen at Cars.com, I decided that it was time to close that season of my career, and I began researching and planning my next career challenge. I outlined three key pillars that were very important to me and my ability to truly enjoy going to work every day:

  • Customer Centric Vision – Having the ability to know WHY what we do matters to customers, and matching values and alignment to priorities.
  • Clear Agile Direction – Finding a company who is moving the agile ball further down the line.
  • Fun and Innovative Culture – Life is too short and if you are going to work hard, it makes it much easier to find the joy in your job if you have fun doing it.

These were the most important traits I was seeking in part because they were the things that made me love being at Cars.com. I plugged into my network, had some interviews (and one offer that didn’t work out), and continued my quest to not settle until I found a career that valued these same traits. Then, just when I thought that finding my career “Match.com” was out of reach, I found an opening for a Chicago-based Product Speversiononecialist that turned out to be the perfect blend of vision, direction and fun.

Luckily for me, it was also at a place I knew very well, VersionOne. After a few interviews and a relatively painless courtship, I accepted the position and can report that so far it has been a jackpot payoff.

Since my start at VersionOne, I have validated or learned seven key things that I believe you can also learn from, no matter where you work:

  1. The customer is king (or queen); however, not everyone is a customer – If the slipper doesn’t fit, you can’t force it!
  2. Community is very important – Sometimes a company does things because it’s for the greater good.
  3. You can’t fake culture – If you’ve got a great culture, you’ve got it. Hang onto it.
  4. Agile is a mindset, not a methodology – Like culture, the question is not “Are you Agile?” but rather, “How Agile are you?” If you aren’t sure, take this Agile Development Quiz.
  5. Cold beer, anyone? A cold beverage and a game of pool after work is still a great way to end the day. When they say “Work Hard, Play Hard,” believe them!
  6. Valuable training is essential – Among the many other benefits, new-hire training as a group bonds people together and to the company.
  7. VersionOne is a great place to be because of the people, agile project management products and services to help companies achieve agile success, as well as VersionOne’s commitment to the agile community at large.

Going into my Product Specialist position I tried hard to find red flags, indicators that would give me some warning or reason to pause. At the end of the day, every flag I saw was Pantone 216. It’s my new lucky number!

I hope you find your lucky number, whether it’s a career at VersionOne, a business engagement with us, or something totally unrelated!

Read more on my personal blog at a12p.blogspot.com.

 

Posted in Agile Adoption, Agile Methodologies | Leave a comment

This is Way Better Than the Ice Bucket Challenge!

If you feel like there’s a lot of time being idled away on the Ice Bucket Challenge and other wacky, brainless activities, we have a better idea to spend your time. In just 10 minutes you could do something really valuable for the agile software community.

But first I’m hoping to get just a tiny smile out of you by sharing something I wrote on our Product Blog earlier this week — just in case you aren’t subscribed there. If you are, just ignore this and go straight to the punch line.

I posed this question:

What’s the Best Way to Spend 10 Minutes?

Let’s think about this for a minute…

You could:

  • Ice-bucket challenge someone
  • Set a stapler in a Jell-o moldStapler
  • Crash someone’s Facebook by inviting them to Candy Crush
  • Add a ‘Blue Screen of Death’ screen saver to your boss’s laptop
  • Load a DVORAK driver onto a PC with a normal keyboard
  • Clean those 24 sticky coffee rings off your desk
  • Assign a bunch of fake stories to people

But if you really want to make a lasting and meaningful impact on the agile software community, please find 10 minutes to take the 2014 State of Agile survey.

Why?

2014_SOA_banner_300x250

“The annual State of Agile survey has become one of the most comprehensive industry surveys serving the agile community. The survey gives agile software professionals an extensive set of relevant statistics, peer guidance and validation that can be very helpful in making smarter decisions about their delivery process.”

– SD Times Editor-in-Chief David Rubinstein

Now in its 9th year, the State of Agile has helps agile practitioners, consultants, technology students, professors, bloggers and business people in all industries better understand agile methods and practices. The survey runs late summer through mid-September and VersionOne publishes the report in Q4 or early Q1.

If you take it, you get:

  • Entered into a drawing for 1 of 9 SONOS wireless HiFi systems (each worth 600 bucks)
  • Exclusive, early access to the data sample from 2,000-4,000 respondents in your industry
  • Satisfaction that you helped others make informed decisions about their agile practices – in just 10 minutes

What are you waiting for? Take the State of Agile survey now.

take survey now image

 

Posted in Agile Adoption, Agile Development, Agile Management, Agile Methodologies, Agile Software, Scrum Methodology | Leave a comment

Bouncing Agile: How Google Analytics is Related to Agile Success

It was a normal day.   I was reading articles, blogs, emails, Tweets, stories and a host of other types of information.  While perusing an item, there was an interesting link and I clicked into another Web location.  When I arrived, the newly presented topic was not what I expected so I navigated away from the site.  Little did I know, this interaction was most likely recorded by Google Analytics as a “Bounce.”

Google states that, “Analytics helps you analyze visitor traffic and paint a complete picture of your audience and their needs.”  Things like Page Views, Average Time on a Page, Entrances and Exits are tracked for behavior.  However, the most interesting metric could be the Bounce Rate.

BouncingBalls

“The Bounce Rate is the percentage of single-page sessions (i.e., sessions in which the person left your site from the entrance page without interacting with the page).”  In other words, they were attracted to a specific page and when they arrived, they left the site without interaction.  The lower the “Bounce Rate,” the longer they interacted with the page and the site.  According to Google, “If you could only choose one metric to look at, Bounce Rate might be your best choice.”

So how does this relate to agile development and agile success?  Similar to a Web page or site interaction, a team with a high “Bounce” rate will not be as productive as one that is stable and has stayed together through more than just a short introduction.  When people are added or removed on a regular basis, there is not time to understand the full scope of work or the people involved in it.

Medinilla states, “The principle of assigning projects to teams assumes that some team stability is needed.  If you are changing team composition every 2 weeks, you are essentially managing a resource pool in disguise.  On the other hand, if you are using agile development’s definition of a ‘team, ‘which is more than a group of people commissioned to do the same job, you’ll need some time for the team to ‘glue’ or, as some experts call it, ‘gel together.’”  (Medinilla, 2012)  It is this unnecessary change, or “Bouncing” that causes confusion, demotivation and poor results in the area of agile success.

There are many benefits to making an agile team stable, one of which is learning.  Alistair Cockburn (2006) asserts, “Novices don’t stay novices forever.  People who are novices on one project become experienced by the end of the same project… This ability to learn along the way helps many projects.  Within a single project’s timeframe, the people learn new technology, new problem domain, new process, and how to work with new colleagues.  Often an agile team struggles through the first 2 increments, becoming stronger and stronger until successful results at the end are almost a given.”  Bouncing from team to team and project to project doesn’t allow enough time to learn technologies, domain knowledge, processes and characteristics of people.

To help track the Bounce Rate of your agile team, Ekas & Will (2013) have recommended a metric: “Validate that you have a whole team; track the team membership each iteration, beginning with the first iteration; and review it regularly.  Confirm that the whole team starts together and finishes together… if the goal is to have stable, dedicated agile teams, then having an indicator immediately available to confirm that this happens can be a big incentive.“

For example:  A team of 5 people starts Iteration 1 with a whole team and completes it with the same 5 people so the Team Bounce Rate is 0%.  Iteration 2 starts with 5 but ends with 4 so the Team Bounce Rate is 20% and the Team Bounce Rate trend after 2 iterations is 10%.  Compare this trend to velocity or throughput after each cycle for evidence of them being connected.

JumpingForJoy

Success with agile development can be measured as a form of bouncing.  Both people and process can be affected by it.  Just as when a reader will try a certain link and bounce back out before truly understanding the main points of the page, so time is a factor in allowing teams to come together properly.

Give your teams a chance to gel.  Give them a chance to learn.  Give them a chance to be successful and maybe the bounce rate will turn into a jump for joy.

References

Cockburn, A. (2006).  Agile Software Development:  The Cooperative Game.  Upper Boston, MA:  Pearson Education.

Ekas, L., & Will, S. (2013).  Being Agile:  Eleven Breakthrough Techniques to Keep You from “Waterfalling Backward”.  Upper Saddle River, NJ:  IBM Press.

Medinilla, A. (2012).  Agile Management: Leadership in an Agile Environment.  Heidelberg, Germany:  Springer Science & Business Media.

Posted in Agile Development, Agile Management, Agile Metrics, Agile Project Management, Agile Software, Agile Teams, Agile Velocity, Iterative Development, Scrum Methodology | Leave a comment