Agile is NOT For You

22135079_xl

Guest post from Daniel Gullo, Apple Brook Consulting

You are talking with two consultants about how to transform your organization into an Agile development company so that you can go faster and keep ahead of your competitors.

You explain to them that your stakeholders have a need to know what is going on and to that end, there are reports that need to be created. Furthermore, your product is governed by Sarbanes-Oxley controls, which absolutely MUST be followed. Funding for your projects is allocated two to three years in advance and is based on detailed estimates, which are in turn derived from the Work Breakdown Structure (WBS) for the project. None of this can change.

You continue to explain that the teams are geographically distributed across four continents and 10 time zones and that restructuring the teams and bringing the teams together, even just for release planning is not possible. Your organization also has no budget to buy things like webcams, additional monitors, team rooms, or even open wall space.

The ScrumMaster in your organization will be “in charge” of 10 to 15 teams and may have other responsibilities as well. Also, the “Product Owner” is really in charge of an entire business unit and won’t be writing any User Stories, so the business analysts will need to be a “Product Owner Proxy” for each team.

After spending 20 minutes relating all of this (and more) to the consultants, including how none of this is negotiable, you ask, “So, what are your thoughts on the best way to implement Agile development here?”

There is silence.

After what seems like an eternity, one of the consultants clears his throat and says “Agile development is NOT for you.”

Did you really just hear that??? Doesn’t this guy get it? Is he really so independently wealthy that he is going to throw away the money that is on the table??

There’s a saying that goes: “If you didn’t get the joke, then the joke was not for you.”

If your company is not open to change or trying new things or running experiments in order to learn, then, Agile is NOT for you.

If your organization is not interested in having happy employees by focusing on people or they aren’t willing to make an investment in tools or to look at simple measurements of customer satisfaction such as the Happiness metric or Net Promoter Score, then, Agile is NOT for you.

If you are not willing to explore what “possible” really means and thus, have an open mind to doing the unconventional, then, Agile is NOT for you.

I’m sorry. I really am.

Agile is not magic. We can’t produce something from nothing or make other trade-offs go away. In order to get X, then you must do Y. You can’t expect to maintain the status quo AND improve. It’s simply not the “real world.”

Agile is all about embracing the uncertainty of change and learning how to use it to your advantage.

As a consultant, I often test the waters a bit when going through the discovery stage with a new client. I might say something that represents a “worst case” scenario to see if they are prepared to go there if it comes to that. I also ask a lot of questions around seeing how they think about people, constraints, etc.

My educational background was in Law. I am inclined to look at possibilities. I often find myself in a workshop or training session orating as if I were in court:

“In your expert opinion as a Senior Software Developer, is it POSSIBLE that you could build production-ready features, albeit very small slivers, that are capable of functioning from end to end by cutting through the entire architecture?”

“No. We can’t produce anything of value in less than six weeks.”

“So, it’s NOT POSSIBLE to release a single field on a webpage with a submit button that applies some business logic and then inserts a value into a table in a database that only includes that field? That’s absolutely NOT POSSIBLE??”

“Um, well, yes.”

“I rest my case, your honor.”

Becoming Agile means being open to possibilities and options.

In a sense, BEING Agile is like acknowledging and understanding what innovation truly means in the same sense that an artist understands what “creativity” means. Is someone who simply slaps paint on a canvas with no understanding of what they are doing considered an “artist?” Most of us would say that they are not.

Likewise, I can explain the agile values, principles, practices, and dynamics of agile culture to someone, but I can’t tell them how to be innovative. That’s something that has to come from within.

It’s uncomfortable, change.

And, through discomfort, we learn and grow.

If you are comfortable with how everything is going, then you aren’t learning.

If you aren’t comfortable with the prospect that Agile is going to make you uncomfortable, then sorry; Agile is NOT for you…

Posted in Agile Adoption, Agile Benefits, Agile Coaching, Agile Development, Agile Leadership, Agile Methodologies, Agile Teams, Agile Training | 21 Comments

The ‘Agile Playbook’

Football players spend a lot of time studying their Playbooks. And Coaches spend a lot of time creating and updating them. These guys are serious. The stakes are high in the NFL; millions of people are watching. Their stated goal is the same each week; to win. That means they gotta work really well together and know what they’re doing.

AgilePlaybook

I think the game of American football is a great example to follow as an Agile team in the corporate world. We all need some help with remembering stuff, and getting it down so we can execute on game day. Even if we’ve done it many times before, it’s easy to get forget; there’s just so much to know and remember. This is hard stuff we’re doing, and it’s in constant flux. We often find ourselves wanting someplace to go for reference, clarification, advice, dare I say… ‘best practices.’

I’ve had several clients (both large and small) ask me for something they could use to document the way they ‘do Agile.’ If they’re new to the game, often they will look to a consultant or Agile Coach to guide them or help create this information.

Enter ‘The Agile Playbook.’

So what is an ‘Agile Playbook,’ anyway?

In short, it’s a helpful guide. It can come in many forms. For now, let’s stick with the football analogy. If you’ve watched an NFL game recently, you’ve probably seen the coach holding up a play sheet, as he decides what play to call. If you (or your kid) has an XBOX or PlayStation with Madden NFL, you know it has a Playbook feature built into it. Note: this could be an interesting feature opportunity for Agile Lifecycle Management (ALM) tool providers, huh? But I digress. So, as for the Playbook itself, I think of this as the larger, over-arching deliverable.

Transferring this idea of an NFL Playbook into the world of Agile software development is natural. I’ve heard it referred to by different folks in similar ways, like ‘Agile one-stop shopping’, or an ‘Agile Coach in a Box’, or ‘How we do Agile here at Company XYZ’. I personally like the term ‘Agile Playbook’ because it’s short, simple, descriptive, and I believe it drives home the team concept nicely.

Who wants an Agile Playbook?

Can you imagine an NFL team without an organized list of plays? So why would we think it’d be any different in our Agile organizations? I remember playing pickup football and we’d draw pictures in the dirt of what we wanted to do. That was fine for a pickup game, but even my nine-year-old son’s flag football team has a playbook. So the question of ‘Who wants it?’ is an appropriate one. If we think of Mike Cohn’s user story template (As a ___, I want to ___, so I can ___), this is the ‘As a’ piece. Who are we doing this for, anyway? Is it the PMO Director? The ScrumMasters? Product Owners? The Team? Program and Portfolio Management? Executives? The answer, in my six years of personal Agile consulting experience, is ‘all the above.’ If they don’t ask about this at some point, it’s usually because they haven’t thought about it yet.

Why do they want an Agile Playbook?

Hopefully, because it adds value. This is the ‘So I can’ part of the story. It’s a guide to help them get where they want to go. It’s something we can point to when someone asks, “How are we doing Agile in our organization?” It’s something we can go to for reference when nobody else is around. It can even be used as an onboarding tool.

The Agile Playbook also gets us thinking not only about how we work, but how we can improve our processes. Are we really being empirical? Give it a little love in your retrospectives. Perhaps there’s an opportunity to update the Playbook. Oh, and if by chance you don’t see any value in it, simply don’t do it.

Yes, it’s a document.

OK, I know what many of you must be thinking by now… The Agile Manifesto says ‘Working software over comprehensive documentation.’ Yes, an Agile Playbook is a document. And yes, it’s likely to be pretty comprehensive. But that’s a relative term; more specifics on this will follow in a bit. The Agile Manifesto doesn’t say documents are evil. In this case, I believe it’s a very helpful and necessary document to have available in order to get everyone on the same page, and to show auditors that our processes are documented (they like that kinda stuff, ya know). An Agile Playbook is a big deliverable. It takes a lot of time, effort and know-how to put something like this together.

When I did one for a client a couple years ago, we employed a full-time Tech Writer for about a month. That was a huge help. I had initially tried to do it on my own, in my spare time, but that didn’t work out too well. The folks in the Agile PMO, including myself, provided the content, primarily.

But I’ve seen other organizations go with almost nothing documented, just pulling in a coach or two and letting it roll. Maybe sharing a few slide decks on an internal page. No strong desire to document the why, when and how we do stuff. I wonder if that’s because they hadn’t thought about it, didn’t want it by design, or just didn’t have the bandwidth. Or maybe there were other reasons. Personally, I believe that not documenting something this important to the agile transformation of your organization is irresponsible.

And having it documented – but all over the place in different formats – can be chaotic. I don’t like to make people go hunt down stuff, let alone guess or assume anything.

My opinion is that this should be as close to one document (or series of web pages) as possible, not multiples; i.e., not nine Powerpoint slide decks, seven Excel spreadsheets, and 12 Word documents with a bunch of buried links to even more documents, slide decks and spreadsheets. Make it as simple as possible. It’s one place to go. One thing to print off (if you desire to have a hard copy) and carry with you for reference. One URL to save as a favorite.

It can help us realize gaps in the way we work.

What I learned early on is that the hard work of creating an Agile Playbook forces us to give a long, hard look at the way we’re working now, and how we want to work in the future. It’s cathartic. It helps us identify areas where we can improve our processes. It forces us to ask some difficult questions. And make some difficult decisions.

One way in which to identify areas of improvement around your process is to identify your value streams. This is a basic Lean principle. I’m sure we’ve all done something like this. How efficient are we in going from start to finish (request to deployment, concept to cash)? Our goal should be to optimize this. Look to reduce delays, inefficiencies, and improve our cycle time.

How do we document tools and technical practices?

Let’s not forget how our tools and technical practices play into this, as they’re an important factor in how we get work done. If your organization is using an Agile Lifecycle Management tool, the Agile Playbook might include best practices on how to use that as well – either melded throughout, or as a separate section.

Same goes for development tools that help us with…

– Continuous integration – Jenkins, Hudson
– Defect Management – Bugzilla, JIRA, HP Quality Center
– Integrated Development Environment – Eclipse, Visual Studio
– Test Management – HP Quality Center
– Source Code Management – Git, Subversion
Agile Portfolio and Project Management – VersionOne, et al.

This can be a lot of information, so when documenting for the Agile Playbook, this is an area where I make heavy use of links to information beyond the basics of each of the tools we use.

It should be comprehensive, yet brief.

If you can’t fit the Agile Playbook into your front pocket comfortably, it’s probably too big. When I say brief, I mean about under 50 pages for a large organization. Any more than that, I think folks begin to feel overwhelmed and push it away. Any less, and it’s hard to be comprehensive. There’s no science behind that decision, but if I apply my own average attention span to the matter, this sounds about right. I think much of this also depends on the format you use: Microsoft Word, Powerpoint, HTML, etc. Again, where appropriate, I like to make liberal use of links to other documents/sources to help minimize the length. I recommend placing it on a well-known organizational site such as Wiki, Sharepoint, etc. Provide a highly visible and pronounced link from your internal company home page, and give the option of printing out a hard copy. In fact, I like to have several hard copies available in the Agile PMO to hand out to folks who want one. You’d be surprised how quickly they go. I’ve found that a nice ringed binder works best. That way, if there are changes, you can swap out a page or two. That said…

Did you know…

Most NFL teams now use tablets (iPad or Surface) almost exclusively for their Team Playbooks?

broncos-120423If you’ve watched ‘Hard Knocks’ on HBO, you already know that the phrase “Turn in Your iPads” has started replacing “Turn in Your Playbooks” when players are cut from an NFL team. Those teams have discovered that the technology goes far beyond the old playbook capabilities. There’s a product called ‘PlayerLync,’ which is at the forefront of this movement. It has revolutionized the way teams push out film and significantly altered the way they communicate. Beyond saving printing costs, digital playbooks are improving the effective, real-time communication by allowing coaches and quarterbacks to add and share plays with the click of a button. Every time new data, film or information is added, a banner alert pops up (like a text message), signaling players to view the updates.

Oh, and PlayerLync isn’t just for professional sports teams. Here’s a short clip on how Chipotle and others are using it to push content to their teams:

http://www.playerlync.com/who-wins-with-playerlync/corporate-communications/

Uniqueness and commonalities

I’ve helped put together a number of these Agile Playbooks for different clients now, and each was both unique. But there are many commonalities, like the general Agile principles and practices. At the end of the day, folks want to know what to do, who does it, when to do it, and why. All these things can be exclusive to the organization or industry. The extent to which Scrum, Lean, and XP practices are applied also varies from company to company.

Fear

The fear seems to be centered around teams in an organization that are using both the framework and the tools differently. It could be that we’re not all using the Agile Lifecycle Management tool in the same way. How in the world can we expect to have rolled up views into the different management levels (Portfolio, Program, and Project) without a common agile project management tool? This opens the door to confusion on many levels, especially when we start talking about agile metrics/reports. But it’s not just the management level that has a problem if we’re not all on the same page. The individual team members also experience fear… fear of doing the wrong thing, or doing it incorrectly, getting called to the carpet or, worse yet, being publicly shamed, written up, or fired. The idea is that if we’re all on the same page, and everyone knows what’s expected, this fear diminishes greatly. Life gets better for everyone.

Start with an outline…

Finally, you were probably wondering when I was going to get here. By the way, each organization’s Agile Playbook is their own. I cannot share the exact Playbooks that I’ve put together with clients, as that information is proprietary. But I can share with you a more generic outline of what an Agile Playbook might look like:

About the Agile Playbook
What is Agile and Scrum?
Implementing Agile and Scrum at Company XYZ
Essentials of Agile and Scrum at Company XYZ (How ‘We’ Do It)
Agile Planning
Agile Execution
Agile Cultivation
Agile Tools
Agile Reporting/Agile Metrics
Staying Compliant with Agile
Company XYZ Communities of Practice (COP)
Conclusion
Bibliography
References

Do you have a Playbook for how you ‘do Agile’ in your organization? If so, what does it look like? If not, why?

Posted in Agile Adoption, Agile Benefits, Agile Development, Agile Management, Agile Methodologies, Agile Project Management, Agile Teams, Scaling Agile, Scrum Development, Scrum Methodology | 2 Comments

My Life as an External Agile Coach (Part 3 of 3)

Here’s the last article in a three-part series from Susan Evans. As we ring in the New Year, this post describes a day in Susan’s life as a Product and Agile Consultant for VersionOne with various client engagements, travel and a family at home.

[Back to Part 1: “99 Problems But Coach Ain’t One”]

[Back to Part 2: “My Time to Evolve as an Agile Coach”]

Working for VersionOne as a Product and Agile Consultant has been a dream come true. All of my Job Satisfaction Acceptance Criteria have been met, and I couldn’t be happier.

Being an agile consultant and traveling for my job were new concepts to me, so thankfully I had the opportunity to shadow some talented individuals to help get my feet wet, show me the ropes, and build my confidence. I’ve experienced agile failing fast, but I’ve also experienced lots of inspecting and adapting that lead to success.

As an agile consultant, I have the chance to share my knowledge and experience with the goal of steering clients away from failure and closer to success. What I love is that I get to help clients in a variety of ways so I’ll never get bored. No two engagements are the same with different clients and their unique cultures, different cities in different seasons, and all of the lively individuals I meet. I’ve been fortunate to work with clients by learning their process and helping to configure and implement the VersionOne agile lifecycle management (ALM) software platform to enhance their agile practices. It’s a great coaching opportunity and a chance to gain insight into how different companies operate.

I also have engagements where I train people who are new to VersionOne, or want advanced training. Both are very satisfying because I get to help people be more proficient with VersionOne, making their agile process that much smoother. I’ve also had the privilege to guide clients through their agile transformation. It’s so rewarding to have people repeat your words back to you and truly be excited to try something new.

Image credit: foxnews.com

Image credit:  foxnews.com

All of those different clients in different cities means that I’ve slowly become a frequent ‘traveler snob’ and can relate to George Clooney’s character in the movie ‘Up in the Air.’ Being that I live in Atlanta and have Delta as a hub at Hartsfield International Airport, the nonstop flights have been great. All other airports and hotels look the same and I complain when I have to take a shuttle to the rental car, or if my room doesn’t have a mini fridge. When I get settled, I take full advantage of being in a new city. I’m an adventurous person and have really enjoyed the travel. I like to explore the touristy areas and have dinner with the locals. I was afraid that I would be lonely, but surprisingly am enjoying my alone time and it’s easy to make friends when I want some company. And my family is just a Facetime away so I can share my adventures with them, too.

I have two children in elementary school, so I was skeptical about traveling and missing out. However, my engagements are typically two to three days during the week with the occasional Monday through Friday. I’m able to block out important dates such as birthdays and recitals to ensure that I’m home.  Thanks to modern technology, I’m able to easily stay in touch with my family. My daughter likes to see my hotel rooms and my son likes to make silly faces at me. I’m still able to talk with them about schoolwork, their friends, and extracurricular activities.

skyclub

I wouldn’t have been able to pursue this career if it weren’t for my very supportive husband, who also works and does a great job of holding down the fort while I’m on the road. I’m thankful beyond measure. I’ve gained so much experience and knowledge but I still have so much more to learn. Thankfully, I have an amazing network of agile coaches from which to learn and an active community to speak with and listen to. The fun is just beginning and I can’t wait to see what’s around the corner!

Cheers!

Susan

 

Posted in Agile Coaching, Agile Leadership, Agile Management, Agile Tools, Agile Training | Leave a comment

My Time to Evolve as an Agile Coach (Part 2 of 3)

This article is the second in a series about Susan Evans’ journey from an internal agile coach to an external agile coach. In this part, Susan will cover how she used the agile principle of reflecting on effectiveness and adjusting accordingly by making changes for the better.

[Back to Part 1:  “99 Problems But a Coach Ain’t One”]

I strongly believe that if there’s anything in my life that I’m unhappy about, it is only up to me to do something about it. So when I found myself considering a complete career change, I knew it was time to inspect the situation and see what needed to be changed. As hard as it was for me to admit, I found that, as the internal agile coach, I was no longer being heard and, therefore, no longer making a difference.

My confidence was shaken until I elicited feedback from the development teams and discovered that they valued my involvement, but they felt that the executives didn’t agree. In fact, they felt the executives were good at ‘talking agile’ but not good at ‘living agile,’ and no matter what I said or did, the culture beyond the development teams would never truly embrace agile.

That was a very sad day… I helped guide agile teams that were growing, shrinking, shuffling, international, self-managed, and completely brand new with an ever-changing process that evolved to fit the situation. Yet, executives still wanted ‘one throat to choke’ instead of understanding that a self-managed team either succeeds or fails together, not due to a command-and-control manager.

manager

I knew it was time for me to do something about it. So I proposed a solution to the CTO, who was my boss at the time. To make a difference again, I needed to be empowered to influence the culture, which meant that I needed to be a peer with the executives as a Director of an Agile PMO. Unfortunately, he was not interested in an Agile PMO Director so this solution was not available to me. I knew that the environment that the CTO would foster and support was not one in which I would thrive and, therefore, it was my time to evolve and move on to a new opportunity.  I asked myself, “What do I do now? In what kind of company and industry do I want to work? What will make me happy?”

To help provide focus and know my priorities, I wrote a simple user story with acceptance criteria:

“As Susan Evans, I want to change jobs so that I enjoy working again.”

Job Satisfaction Acceptance Criteria:

  • To make a difference and help people and organizations be happier and more productive and, therefore, proud of my work.
  • To respect the leaders of the company I work for in their ability to grow the company and do the right things for their customers. I wanted to work hard to make money for my executives.
  • Work for an agile organization… I CANNOT go back to the “dark side!”
  • Work for an established and stable medium-sized company where I can work with, and get exposure to, many departments.
  • The culture of the company must be causal with attire and work hours, and strive to have happy employees with fun activities during and after hours. I want to feel a part of a hardworking family.
  • I want to be challenged and provided the opportunity to learn and grow my skills.
  • I want a supportive manager who will trust me to do my job to the best of my ability and provide guidance when necessary.

As Peter Saddington said during a speaking engagement at a Scrum Meetup in Atlanta, life is too short to hate your job. So, I challenge you to write down and prioritize your acceptance criteria for job satisfaction and assess how you’re doing.

Don’t miss my wrap-up (Part 3) of this series coming soon, where I will discuss my experiences as an external agile coach.

Back to Part 1:  “99 Problems But a Coach Ain’t One”

Posted in Agile Coaching, Agile Leadership, Agile Management, Agile Project Management, Agile Teams, Scrum Development | Leave a comment

99 Problems But a Coach Ain’t One (Part 1 of 3)

This article is the first of a three-part series that provides insight into what it’s like to walk a mile in an agile coach’s shoes. Susan’s journey starts as an internal coach and then evolves to her current role as an external consultant.

I was a rockstar for the first nine months to a year as an internal agile coach helping to improve various areas in application lifecycle management (ALM). Once the easy issues were resolved and we were left with the hard executive and cultural changes, then my returns were diminished and it became harder to see how I was making a difference as an agile coach. Even when change was happening all around us (team assignment, desk location, code build tool, projects/product owners, deployment process, agile process, ALM software, etc.), it was still very time consuming to see the results of my influence. With every issue we were able to check off the list, it felt like there were 99 more problems to address.

I started documenting all of my ‘Proud Mommy Moments’ where we were successful so I could see the progress we were making. I read Lyssa Adkins’ book “Coaching Agile Teams” for new ideas and reassurance that I was doing what I was supposed to be doing. But most importantly, I stopped blaming myself for the failures. As an agile coach, ‘keeper of project management,’ with a growing list of issues to address, you feel like you have the weight of the world (well the company) on your shoulders and it is up to you to champion improvements in the ‘broken’ process.

But you can’t do it alone.

I was able to get the right people together to talk through the issue and determine a solution. We even communicated the change to all involved. However, many of the decision makers and key leaders never changed their way to follow the new process. I took this very personally, thinking that they did not respect me and I felt like a failure. It took several conversations over beers with my boss and my agile mentors, Scott Brown, John Miller and Luanne Willimon, to realize that, while it was my responsibility to set and communicate the process, it was not my responsibility to enforce individuals to follow it. I had neither authority over them nor the ability to influence them. I can provide guidance, therapy sessions, suggestions, and pros and cons around decisions, but I couldn’t make them do anything.

 

quote

Up next in this series – Part 2:  “My Time to Evolve”

Stay informed. Subscribe to the Agile Management Blog now.

Learn about VersionOne’s ALM software

Posted in Agile Coaching, Agile Leadership, Agile Management, Agile Project Management, Agile Teams | 2 Comments

This Isn’t a Race!

Have you experienced problems with competition amongst team members/developers within a Sprint. A Sprint is a race, after all. Most people associate this term to mean a short dash, going as fast as you can, competing against a number of others. There’s a great new show called Silicon Valley (by Mike Judge of Beavis and Butthead fame) that shows this dysfunction on a Scrum team.

Silicon Valley Scrum Pic

http://youtu.be/oyVksFviJVE (Warning: funny, but slightly inappropriate in areas)

After watching this, ask yourself, are we truly a team trying to achieve a common goal, or are we still individuals competing amongst one another? How do we measure progress? How do we reward folks? How do we handle the type of dysfunctional behavior in the above video, and who does it? Is this is a reason to begin using the term Iteration instead of Sprint?

In my experience, I’ve not seen the competition quite so blatant amongst developers as in the aforementioned video. But I have seen it. And as a Scrum Master and an Agile Coach, I have pointed them back to the Agile Manifesto’s 12 Principles…

http://www.agilemanifesto.org/principles.html

The one that stands out, to this point is…

Working software is the primary measure of progress.

In other words, we’re not measuring lines of code written, or story points completed, or hours worked. We’re measuring working software completed, at the Team level. Did we, as a Team, meet our Sprint goal, and deliver something valuable to our customer through early and continuous delivery.

Velocity is another metric that gets misconstrued, in my experience. At the end of the day, velocity is a planning metric for the Team. We shouldn’t use it as a measure of speed compared to another team or another individual; i.e. I’m a great developer because I was able to complete 4 stories for a total of 20 story points in this 2 week Iteration. The guy sitting next to me only got 10 story points done. Therefore, as their logic goes, I’m twice as good a developer as him. And I should be compensated accordingly when it comes bonus time.

Yeah, but what if we have slackers on our team, and there’s really only one or two people doing a majority of the work? Well, there’s probably a reason for this behavior, actual or perceived. My advice is to dig in to the root cause. Clearly fodder for the Retrospective at the end of the Iteration (a.k.a. Sprint). Beyond that, it’s really up to the Team to resolve if they can. Escalate as necessary.

My initial assumption starts with the idea that we have self-motivated individuals on our Teams. And that it’s my job as a Scrum Master to provide them the environment and support they need to get the job done. If I can’t do that myself, I get help. Servant leadership.

What experiences have you had with intra-team competition?

Posted in Agile Adoption, Agile Management, Agile Teams, Scrum Methodology, Uncategorized | 2 Comments

Sutherland Answers Top Questions from AgileLIVE “Power of Scrum” Webinar

agile-and-scrum-webinarGuest post from Jeff Sutherland, co-creator of Scrum and CEO of Scrum Inc.

In case you missed it, earlier this month VersionOne broke record attendance (5,000 registrants) for our AgileLIVE webinar series. Jeff Sutherland keynoted the event with a focus on “doing twice the work in half the time” with agile and Scrum principles.

Jeff must have said something right because the attendee questions flooded in. Since we ran out of time to answer all of them on the live webinar, we asked him to answer the most common questions right here for you to learn and share. If you find these helpful, please download the full recording of AgileLIVE: “Getting to Done – The Power of Scrum.”

Q: Do we need some initial design done before we engage a developer?

A: The designer should be part of the team. How much design needs to be done should to be worked out in the team before coding begins? This question is similar to, “Do we need a tester before we can ship?” All people necessary to get to Done need to be on the team working as a team.

Designers struggle with this concept when they are not cross-functional and tend to work across teams. At Scrum Inc. we put a design expert on one team even if they have to help other teams.

Q: How is Story definition effectively managed? Is Story definition considered part of a Sprint?

Getting user stories or product backlog items in a ready state takes place during the previous sprint in product backlog refinement. The Team and ScrumMaster should expect to spend about 10% of their time working with the Product Owner to refine the stories for the coming sprint during the current sprint. We have tried to make this clear in the Scrum Guide at scrumguides.org.

Q: We know that Scrum can be applied outside of coding software. What generic term would we replace “Working Software” with in the Agile Manifesto for efforts that are not software development efforts? Working Deliverables?

Joe Justice leads our agile hardware practice. He uses this wording:

“The Agile Manifesto applies to all industries. When we read it and its 12 principles, and switch each mention of “software” with “customer visible value,” we have an elegant methodology that applies to all business.”

Q: We are applying agile and Scrum methodologies to marketing efforts (with adjustments for marketing). Have you ever worked with or witnessed agile in other areas beyond software? Do you think it works?

One of the driving motivations behind publishing my new book, “Scrum: the Art of Doing Twice the Work in Half the Time” was to show how effective Scrum could be in all industries. In fact 80% of the examples in the book are non-software related.

My company Scrum Inc. is a business services organization and we Scrum everything: marketing, finance, sales, and content creation. Many of the companies I work with use Scrum in marketing. Sometimes the marketing Scrums are better than the development Scrum teams.

Q: What are some of the approaches you recommend for getting to consistent story points, especially across teams?

Getting consistent story points across teams is not important. What you want to look at is acceleration across teams. Teams will estimate in ways that makes sense to each individual team.

However, Scrum Inc.’s Chief Product Owner Alex Brown has conducted a number of experiments. He found that dropping similar backlog items into different teams’ backlogs can give a Product Owner a pretty good idea of point variability between teams. He then estimates how long it will take to complete an epic that is being worked on across multiple agile and scrum teams.

Q: What is your view on LeSS (Larman and Vodde) and Scaled Agile Framework® (SAFe™) by Dean Leffingwell.

For non-agile organization’s looking to transform, LeSS and SAFe might be good places to start. However, these prescriptive scaling frameworks can eventually become a major impediment as the organization’s agility matures. LeSS is closer to Scrum principles. SAFe adds extra overhead.

We talk about the basic components of scaling in our Scrum@Scale online courses at scruminc.com. There we describe where SAFe and LeSS might be useful. We also point out that scaling agile needs to fit the organization and its goals. A company like Spotify would not use prescriptive frameworks. Large companies we work with that start with SAFe soon find they need to change the organization and eliminate waste, which moves them beyond SAFe. Dean Leffingwell points out that SAFe is a starting point.

Scrum is fractal and based on Object Oriented Architecture. It was designed to scale. In fact, the first scaled Scrum pre-dates the Agile Manifesto by many years. It was similar to the approach Spotify uses today.

Related links:

Product info – Scaling agile and scrum with VersionOne

Webinar recording – AgileLIVE: “Getting to Done – The Power of Scrum”

Blog post – SAFe and Other Frameworks for Scaling Agile

Blog post – What is the Prerequisite of Success When Scaling Agility?

 

 

Posted in Agile Adoption, Agile Benefits, Agile Development, Agile Marketing, Agile Teams, Scaling Agile, Scrum Development, Scrum Methodology | Leave a comment

‘Twas The Night Before Sprint Planning

daniel gullo ABC consultingWe hope you enjoy this holiday poem on Sprint Planning. It was an early holiday gift to the Agile Management Blog from Daniel Gullo, owner/principal of Apple Brook Consulting. Thanks, Daniel!

‘Twas the night before Sprint Planning, and all through the Team
Not a member was worried about the upcoming theme.

The Stories were refined and the Backlog was set;
Poker had been played without a single bet.
Appropriately sized and estimates all sound;
Acceptance Criteria to establish firm ground.

The ScrumMaster and Product Owner had just finished a call,
To talk about ordering and a potential Sprint Goal.

The Retro had happened several days prior;
The Scrum Team had discussed how to move the bar higher.
Agreements were revised and the Definition of Done
Included more testing and other such fun.

The stakeholders were eager to see the new stuff:
“The product has value!! Perhaps we have enough??”

In the last Sprint Review, the Team had shone bright,
A shippable increment, a product in its own right.
Wouldn’t be long ‘til the Team would release,
Causing the customers’ delight to increase.

The CEO and the VPs were finally content,
The decision to be agile had caused no lament.

Developers are happy in practicing their trade
Testers are ecstatic they are no longer blamed.
And everyone has a chance to really collaborate
Without worrying about the build being late.

As dawn approached and meeting was nigh,
The Team members were up on an adrenaline high;
Excited to move forward and full of new hints,
The wonder of Scrum and working in Sprints.

“Is agile right for me?” you may be wondering,
As your organization continues with delivery blundering.
If your culture is ready to be focused on learning,
Agile will help you return to positive earning.

Blessings-

Daniel Gullo
CSC, CST

Get more info on sprint planning within VersionOne.

Posted in Agile Adoption, Agile Benefits, Agile Teams, Agile Testing | 1 Comment

Secret Sauce of Running a Great Scrum Team

In this guest post by Jeff Sutherland, co-creator of Scrum and CEO of Scrum, Inc., you will learn five reasons why 49% of agile projects fail – and how you can avoid it.

jeff sutherlandMy book, “Scrum: The Art of Doing Twice the Work in Half the Time,” was published in October. Over the last six weeks, I’ve been touring the U.S. and Europe telling the story of all the influences that culminated in the creation of the first Scrum team over 20 years ago. No matter where I go, people ask me what the secret is to running a good Scrum. The secret sauce of running a great Scrum Team is Getting to Done!

Bad Agile

There is a lot of “bad agile” out there. According to Jim Johnson at The Standish Group, 49% of agile projects fail. Why? Because people don’t grasp the essence of what it means to be agile. It requires a fundamental shift in thinking. The second value of the Agile Manifesto is quite clear: Working software over comprehensive documentation. That means that at the end of each and every Sprint you have potentially shippable increments that work!

Working software is key because it is the catalyst for one of the most important aspects of the Scrum Framework: feedback. If you don’t have working software at the end of the sprint, stakeholders can’t use it during the Sprint Review and, as a result, can’t give the Product Owner and team the feedback that will allow the team to develop the product into the customer’s sweet spot.

The secret to working software is complete testing inside the Sprint. If your agile testing practices aren’t tip-top, your teams are probably struggling, your customers are probably frustrated, and you most likely don’t know when the product will ship.

Five Causes of Team Failures

1.  Poor definition of DONE
2.  Stories not READY
3.  Dysfunctional Leadership
4.  Technical Debt
5.  Ineffective coaching

A rigorous definition of Done includes working tested product at the end of the Sprint. Teams must work together to refine their definitions of Done. Product Owners have to stop accepting Stories that don’t meet these criteria.

Good definitions of Ready and Done are two levers that produce successful Sprints. Stories don’t magically become Ready; they need to be clarified and granulated. Acceptance tests need to be embedded. This takes time and attention from the Team.

A leadership team that sees the benefits of going agile, but hasn’t engaged enough to shift their mindset, is a recipe for disaster. Scrum works because it allows capable workers to self-organize and determine how best to accomplish their goals. If management maintains a command-and-control mindset, a Scrum implementation will fail.

In an agile context, managers become leaders. They are tasked with setting transcendent goals for the organization, supporting the teams and removing organizational impediments. They need to determine what Scrum metrics would best bring transparency to the processes so they can hold the Product Owners responsible for value delivery and ScrumMasters responsible for velocity.

Technical debt needs to be stopped in its tracks. The discipline of having clean code every day is essential, as is completing all testing within the Sprint. Then the historic technical debt can be reduced piece by piece.

When implementing an organizational change, companies are pretty good about educating their employees but they fail to provide them with support they need to succeed. The most successful implementations not only get their workers certified but also bring in outside agile training and consulting services help to launch the teams.

A team launch includes an expert coach who helps develop the first iteration of the Product Backlog, helps the teams define what it means for a story to be both ready and done, and leads them through all the Scrum ceremonies at least once. Ideally, the coach returns periodically to fine-tune the teams’ work and take them to the next level.

In Conclusion

Systematically focusing on remediating these issues will consistently produce high performing teams with 200% to 400% improvement in production.

Failure to focus on them will add yet another team to the 49% of teams that are “Bad Agile,” leading to unhappy customers, lost revenue, and lower stock prices.

For more information, grab the recording of my recent AgileLIVE webinar: “Getting to Done – The Power of Scrum.”

 

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

Agile Teams Should Sprint, But in the Same Direction as Enterprise PPM Strategy

CA logo

 

Guest post by James Chan, director, technical presales at CA Technologies

James-Chan

Catch James Chan’s talk on AgileLIVE Wednesday, December 10, 2014: “Portfolio Strategy + Agile Execution: Coordinating, Not Competing.” Details at http://pm.versionone.com/AgileLIVE-2014-CA-PPM.

I think we can all agree that agile techniques have made their way into large enterprises. As agile adoption crosses the threshold into large enterprises, agile teams sometimes begin to struggle with determining the items of highest business value when delivering syndicated enterprise solutions.

Depending on which client the team interacts with, the definition of priority and business value can easily fluctuate. In large enterprises, product owners and agile teams need some way to connect to the bigger picture of enterprise strategy and ensure that enterprise goals are met, while being fiscally responsible to deliver on items that are being funded.

To add an additional level of complexity, enterprises may have pockets of agile work, as well as pockets of traditional work. Enterprises are rarely homogeneous. In many cases, enterprises run under a hybrid model, where the development and QA teams leverage agile techniques, but other teams such as the PMO, product management, sysops, enterprise architecture, user experience, and devops may use other techniques.

Because enterprises live in this space, there needs to be a way for those in charge of strategy to perform their market-sensing activities to develop, define, select, and fund an enterprise’s strategy. This strategy then needs to be communicated to those responsible for product delivery to align them with strategy and identity problems they can solve, as well as opportunities they want to exploit. Once these items of highest business value are defined and prioritized, that vision can then be communicated to the execution teams to realize the vision in a manner that is most effective for them and the enterprise.

To ensure that everyone in the enterprise is rowing in the same direction, and to fully realize the benefits of agility, enterprises need to take a look at the bigger picture. Many are looking at agile execution techniques as part of a larger enterprise ecosystem through project and portfolio management solutions. Enterprise PPM (portfolio management) helps with alignment, enabling enterprises to couple speed with thoughtful planning. Project and portfolio management solutions help portfolio managers define the enterprise’s trajectory needs and balance initiatives that support the strategy with financial capital and human skills. They can also collaborate closely with product management to define the problems they should solve as well as the opportunities they want to exploit in support of the enterprise’s vision.

Finally, that collaborative roadmap needs to be the guiding force for agile execution teams to ensure that as they are sprinting, they are sprinting in the same direction. If teams just focus on the smallest unit of work, which is a user story, they can quickly lose sight of value and get lost in the trees. So in order to ensure that teams drive toward overall delivered business value, enterprise strategy and trajectory need to be taken into account.

So how do you do this? A good place to start is by checking out the CA PPM (Project and Portfolio Management) integrated solution with VersionOne. This unified enterprise PPM solution gives you a clear picture of all projects from the top down, from high-level feature planning to work item assignment. By combining strategic, financial portfolio management capabilities with ALM software, you can get your agile teams sprinting in the same direction as your enterprise strategy – so business value gets delivered faster and the transition to enterprise agile is simpler.

James will present on this topic during VersionOne’s AgileLIVE™ webinar on Wednesday, December 10, 2014 from Noon to 1 p.m. EDT. Details and registration:

AgileLIVE: CA PPM and VersionOne webinar:

“Portfolio Strategy + Agile Execution:  Coordinating, Not Competing”
December 10, 12-1 p.m. EDT

Posted in Agile Portfolio Management, Agile Teams, Enterprise Agile, Scaling Agile | Leave a comment