Make Agile 2014 PEACHy

This year, I’m excited to be returning the Agile Conference. Having organized and participated in the conference from 2001-2005, my attendance became sporadic as the beginning of the youth football season (my other coaching gig) won out over the annual agile pilgrimage. Preparing for the show brings back many memories, but also some lessons learned that I wanted to share for anyone new to the conference or looking to get a little more out it. In true agile form, I’ve made a pithy acronym. Follow these suggestions and after the conference, you’ll be saying, “That’s a PEACH, hon!”

The Agile Alliance Agile2014 Pre-Conference Planner is a great resource for planning your conference activities. Obviously, you’ll get the most out the conference if you review the sessions and target the sessions you don’t want to miss (MoSCoW anyone?). For your most important sessions, check out the room size. As part of a commitment to an open learning environment, the conference does not reserve seats, nor limit your ability to participate. The most popular sessions will fill their rooms, leaving some standing or not able to attend. In your conference guide, you can get a sense of the room size. If your must-see session is in a smaller room, GET THERE EARLY!!

There is great content to choose from. Pick your targets, but include one or two sessions that are out of your box and may give you empathy for someone else’s kind of work. If you need ideas, check out these sessions being given by the nearly 20 speakers from VersionOne and our partners:

VersionOne: Matt Badgely, John Krewson, Steve Ropa
agile42: Richard Dolman, Martin Kearns
Cognizant: Raje Kailasam
DavidBase: Jeffery Davidson
DevJam: Matt Barcomb, David Hussman
Improving: Ken Howard
LeadingAgile: Mike Cottmeyer, Derek Huether
Lithespeed: David Bulkin
SolutionsIQ: Daniel Gullo, Tim Myer, Dhaval Panchal, Charlie Rudd, John Rudd

The conference can be overwhelming with tons of people, tons of sessions, tons of exhibitors (read: free stuff!), tons of activities. Sensory overload. So pick your focus , but try at least one thing that will stretch you a little, socially and intellectually.

If you are new the conference, I highly recommend the First Time Attendee Orientation. At that session you’ll see everyone else who is wondering about the things you are and then some. The Early Registration Meet & Mingle and Ice Breaker Reception (Moscow mule, anyone?) is another great way to start the week. Between sessions, look up from your screen enough to meet some new folks and hang out. Dinner with New Agile Friends is a great way to meet people, especially if you are not attending with a group of colleagues. And, of course, the Conference Party should not be missed.

Don’t miss the Sponsors reception and the booths through out week. Check out our @VersionOne mobile photo challenge on Twitter where you can win daily prizes or a GoPro HERO3+.

You’ll learn new things about the conference as you go through it. Your time is the most valuable thing to manage, with perhaps sleep a close second. Use the Open Space Law of Two Feet to adapt what you do. Is a session not quite what you expected? Don’t be shy, get up and move on. Take the time to find another session, hang out, catch up with those incessant emails and posts, or just take a breather (or nap)

You develop deeper understanding by interacting with others. The conference favors interactive sessions, but there are many other ways to share and learn. Be sure to swing by the Open Jam and catch the latest buzz. The Scrum Alliance is holding a Coaches Clinic each day where you can share ideas and challenges with Scrum experts. Our conference organizers, the Agile Alliance will have the Agile Alliance Lounge open each day.

And if you see any of us VersionOne folks, in our sporty shirts, please stop us, introduce yourself, and mention what a wonderful blog post this is. We love agile and learning by sharing with others.

The most valuable experiences I hear about are the interactions people have hanging out in the hallways. These by-chance encouters lead to amazing insights and relationships. If you are are an extrovert, this will come naturally. If not, here are a few tips:

  • The Agile conference has always been known for its community atmosphere and approachable speakers and attendees. Its kinda who we are. So, realize that you are in an environment that specifically values Individuals and Interactions.
  • It may be awkward at first. Yes, it can feel very weird to approach someone you don’t know and initiate a conversation. Work to overcome that fear (for the XPers and Scrummers, this is living up to your Courage value). Asking about a favorite session or the basics like what one does in their job are simply ways to get a conversion started.
  • Don’t give up. Not every encounter will be amazing. If a conversation does not take off, no worries, the next one prpbably will.
  • Approach a group. If you hear a small group talking about a topic of interest to you, don’t hesitate to approach, express your interest in the topic and join in. You’ll be well received and add another interesting perspective to the dialogue.
  • You probably know more than you think. Many attendees have told me after the conference, “you know, from our experience, we know as much as most of the people at the conference.” If you are feeling intimidated that others seem to know more than you, realize that either a) they don’t and are just more comfortable talking about what they know or b) were in your shoes just a few years ago and are passionate about helping you learn what they’ve learned.

Do you have recommendations for conference goers? Please share them by commenting below.

Have a great conference. I hope our paths cross during the week.

Posted in Agile Coaching, Agile Development, Agile Management, Agile Portfolio Management, Agile Project Management, Extreme Programming, Kanban, Scaling Agile, Scrum Development | Leave a comment

Agile Software Needs Craftsmen

rock ridgeSo, you want to be an Agile shop.  You’ve read all kinds of cool stuff about Sprints, and WIP limits, and daily stand-up meetings.  You even think you get this crazy User Story and Planning Poker stuff.  You put together a room with snacks and lava lamps.  You have all of your stories in a cool ALM tool like VersionOne and displayed on a wide screen TV.  So you’re ready to go, right? Well….maybe not.  You are missing the most important part….the people.  Remember that one of the principles of the Agile Manifesto is to “Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.” In order to be successful, we need more than just motivated individuals, we need motivated Craftsmen.

Lets start with a disclaimer.  I use the term Craftsman in a gender neutral sense.  If folks feel like I should change this to Craftspeople, let me know and I will.  I get a lot of inspiration from the Software Craftsmanship movement, which tends to use the word Craftsman.

So what is a Craftsman, and what does that have to do with Agile?  Agile is hard.  It is a very highly disciplined approach to software development.  It also is very fast moving.  If we expect to be able to “welcome changing requirements, even late in development”, we need to have people with a high degree of skills in order to do that.  A craftsman is someone who takes the craft of programming seriously.  One who will not do garbage work, and will not accept garbage from her peers.  Lets take a look at the values delineated in the Agile Manifesto:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

We’ve all seen these many times, but let’s now look at the Craftsman’s Manifesto.  You can find a link here: Manifesto for Software Craftsmanship

Not only working software, but also well-crafted software
Not only responding to change, but also steadily adding value
Not only individuals and interactions, but also a community of professionals
Not only customer collaboration, but also productive partnerships


So really, they are symbiotic.  A well performing Agile shop will have Craftsmen as the vital part of their team.  A team of Craftsmen, by their very nature, will be embracing those values and principles of the Agile Manifesto.  So don’t forget the people as you build your Agile shop.  Create an environment that encourages those great practices like Test Driven Development and Continuous Integration.  Allow your team members the freedom to practice their craft, and the opportunities to enhance their craft.  In the end, you will have your motivated individuals who will delight in getting the job done.

Posted in Agile Adoption, Agile Benefits, Agile Coaching, Agile Development, Agile Management, Agile Methodologies, Agile Software, Agile Teams, Agile Testing, Agile Tools, Agile Training, Continuous Integration, Distributed Agile, Enterprise Agile, Extreme Programming, Iterative Development, Kanban, Lean, Lean Software Development, Scaling Agile, Scrum Development, Scrum Methodology, Scrum Software, Scrum Tools, Test Driven Development, Uncategorized | Leave a comment

Problem Solved: Formula to figure out How Much Detail is Required with Agile Requirements

WARNING: Shameless plug for my session at Agile2014 ahead.

I recently got the priviledge to listen to Alistair Cockburn talk to a small group at the VersionOne offices. He told the story about Kent Beck and how the idea of how the user story on notecards was born (I’ve read about this before, but it was great hearing it from Alistair). He talked about how the card was just that — a card with a title that reminded the developer and the target customer/user what they were building, maybe there were a few notes jotted down on the card. The narrative about the story wasn’t captured on the card — the details were verbally communicated because the developer and customer were all in close proximity of one another — they did this crazy thing, they simply walked down the hallway and talked.

In addition to this story, Alistair spoke about his experiences with a team that had development in Singapore and the business folks and architecture worked in the states. The company was having challenges with the team in Singapore at getting things done efficiently and, in some cases, getting things done right. It seemed like there was an inordinate amount of time that had to be spent on discussing requirements and getting questions worked out. The company decided to send some of the business and architect team members to Singapore to work out some improvements. When they did — the quality and productivity went up. When they returned, it took just a couple weeks before productivity slipped and all gains were lost. The reason for these results seems obvious — timezones, communication barriers, and not being able to have impromptu conversations can have a great impact on how well teams understand the requirements especially since a lot of conversations capture the specifics.

Hearing these two stories triggered some ideas in my head, and I thought — why can’t there be a simple formula we can use to gauge the amount of detail (words) we capture in a story to make it work. Through some hard work — I’ve now have that formula.

Here are some factors that I think go into figuring this out:

  • Complexity – just how well does the team understand the story and how hard the team thinks it will be, either from experience or flat out guessing. Usually captured as story points.
  • Difference in Timezones – the number of hours that separate us greatly impacts how fast communications can happen, especially if the communications occur near the bookend points of the day.
  • Auditing Requirements – audits are generally costly and require an additional amount of documentation overhead.
  • Multiple Offices – when people are in different buildings, it raises the amount of details that have to be captured.
  • Offices on Different Continents – although this somewhat relates to timezones, there is also the fact that people speak different languages. Even if they all agree to use english as the primary business language, there’s still slang, accents, and even cultural differences that impact communications.

How Long the Team has Worked Together – knowing each other is key, we figure out accents, we are able to exchange less verbal words, and we learn how to work with one another — what level of information is required to work effectively as a team.

So I reached out to some friends and the folks at Tagri Tech, and with their help — here’s the formula we came up with:

Amount of Words in Story = (Complexity * (1+ max absolute difference between timezones) * (1 + # of annual audits) * (Total # of locations * # of continents)) / (# of quarters the team has worked together)

And here’s the formula in action:


Multiple simulations have been ran and I found that the formula works in less than 0.01% of the situations. The people I’ve been working with at Tagri Tech’s statistics analysis department have ascertained that every team is different, and every product is different — this means that no matter how much documentation you have — the people involved in creating the documentation or the target consumer of the documentation really are not going to read it. They found that while some documentation like compliance reporting and end user documentation are necessary, much of the collaboration level docs are only consumed by the person that created it.

Ultimately, Teams will generally work together to figure out how much details are truly required to facilitate working effectively. If your teams are having challenges with how much documentation is required within Agile Software Development projects, then please come to Agile 2014 and check out my session on Friday at 9AM in the Sanibel room, we’ll talk about some ways teams can workout their own formula.

Update: Hopefully you read all the way to the bottom of this post and realize, this is just a ruse, a joke, a farce, me not being serious. My point is, agile is hard and the concepts of documentation around building software makes it difficult as well. The right amount of details in our requirements is a trial-and-error thing, sometimes you’ll have too much details and at times too little.

Posted in Agile Adoption, Agile Coaching, Agile Development, Agile Methodologies, Agile Teams | Leave a comment

With Me It’s All or Nuthin’

Forgive me for bringing up show tunes.  I love the old musicals. One of the true classics of American all or nothingtheater is the show Oklahoma.  I got to thinking about this in a very roundabout way the other day.  The song, called “With Me It’s All or Nothing” got stuck in my head.  Let me tell you why…

If you like to cruise the various discussion groups, you will find to time see a question “When it comes to Agile practices, which ones should I do first?” or “Which Agile Practice is the most important of all?”  These questions are fun to argue about.  They are mental candy.  But the bottom line is, just like candy, they can also be bad for you.  If we decide that iterative and incremental development is the most important aspect of Agile, does that mean we can get rid of Test Driven Development?  Or, if we decide that Continuous Integration is the most important practice, does that mean we can break out the Gantt charts?  I don’t think it does.

The most egregious example I have seen in this, and it is unfortunately quite common, is the mistaken belief frustrated-programmerthat we can do all of those nifty Scrum ceremonies and activities, and ignore the development practices that make Agile work.  If you have  an iterative process that embraces change, even late in development, but have none of the practices that make that possible, you just have a lot of tired, frustrated programmers. This may be the source of some comments we’ve seen on this blog lately that say “I hate Scrum”.  I often wonder if it is Scrum that these folks hate, or if its the fact that only part of it is being used.

I’ve always seen Agile, or more specifically the implementation of Agile, as a whole package kind of deal.  The real power of Agile software development is not the fact that you do things in smaller increments, orpepperoni and mushroom pizza that you write your code test first, but in the supporting power of each of these elements.  The whole is so much more than the sum of its parts, that I can’t understand why one would chose to not implement the whole thing.  Its sort of like buying a pepperoni and mushroom pizza, then picking off all of the mushrooms.  If you didn’t want mushrooms, why did you order the pepperoni and mushroom?

This all came about because of a rather heated discussion around what is more important, Acceptance Test Driven Development, or Unit Test Driven Development.  The “antagonist” in this argument was contending that since the Unit Tests are “just for the developers” they really were unnecessary, and Acceptance Tests were all that was required.  After a while I couldn’t help but ask “why are we arguing about this?”  The real answer is we need Acceptance Test Driven Development, we need Unit Test Driven Development, Refactoring, Continuous Integration, and yes, Pair Programming.  You see, with me it really is All or Nothing.


Posted in Agile Adoption, Agile Benefits, Agile Coaching, Agile Development, Agile Management, Agile Methodologies, Agile Project Management, Agile Software, Agile Teams, Agile Testing, Agile Tools, Continuous Integration, Enterprise Agile, Extreme Programming, Iterative Development, Scrum Development, Scrum Methodology, Test Driven Development, Uncategorized | Leave a comment

Lots of carryover? Try swarming

swarming4Scrum teams are made up of individuals with cross functional skills that commit to completing the sprint backlog as a team. Instead of a traditional Project Manager assigning tasks, the team decides how they are going to get the work done and individuals choose or sign up for the work they want to do.

If on sprint planning day, the team determines the owner for every task, then it’s very easy for our introverted development teams to go heads down at their desk and only focus on their personal ‘to do’ list. Even though they are having a daily stand up, if they are not truly paying attention to how the team as a whole is tracking according to their plan, then teams can end their sprint with several backlog items partially completed. The team has to own up to the stakeholders during the sprint demo that they didn’t meet their commitment and that walk of shame is no fun. Plus, a backlog item that is 90% complete does not make the company money so the team discusses in the retrospective how to prevent that from happening again.

I would challenge a team who finds themselves in this situation to no longer determine the owner of tasks on sprint planning day. Instead, allow team members to sign up for a task daily throughout the sprint following the swarming approach. Like when worker bees swarm together to build a new hive, teams should swarm together to work down the prioritized sprint backlog. On the first day of the sprint, the team should put only the top backlog item in progress until it meets the definition of done. Once the top backlog item is done, then the next backlog item in the list can be put into progress. Based on the size and skill sets of the team, they may find that their WIP limit is two to make sure everyone has a task on the first day of the sprint. To help enforce this, the team can set a WIP limit of one or two on the ‘In Progress’ column of their story board. This focus will:

  • Keep the team working together closely and will result in less context switching
  • Keep the intensity level high on getting impediments resolved ASAP
  • Forces the team to test early in the sprint instead of it becoming a bottleneck at the end
  • Product Owner can provide feedback, verify and accept a backlog item early in the sprint instead of on the last day

The Product Owner who has three backlog items done and accepted feels a lot better than the Product Owner who only has seven items that are 90% complete.

Posted in Agile Adoption, Agile Benefits, Agile Coaching, Agile Management, Agile Methodologies, Agile Portfolio Management, Agile Project Management, Agile Teams, Agile Velocity, Enterprise Agile, Kanban, Scrum Development, Scrum Methodology | 2 Comments

Agile Beyond Software: A Manifesto For All Industries

Lean ManufacturingWhen the Agile signatories created the Manifesto, software was obviously at the core of their thinking, which makes sense as they were all building software at the time.  As it has grown in its popularity, however, Agile has gone beyond software.  So, should the original Manifesto be adjusted to accommodate these new adopters?

There is an ongoing debate about whether Agile is only for software development or whether it can be applied to other industries.  In order to even attempt to see if Agile could be applied, we should first take a look at the original values and principles, which you can find here:

With that, here is a stab at what it might look like if it were to change. I’ve underlined any text that has been altered from the original:

Manifesto for Agile Product Development

We are uncovering better ways of developing
products by doing it and helping others do it.
Through this work we have come to value:

Individuals and interactions over processes and tools
Working products over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on
the right, we value the items on the left more.

Here are the principles with changes:

Principles behind the Agile Manifesto

We follow these principles:

Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable products.

Welcome changing requirements, even late in
development. Agile processes harness change for
the customer’s competitive advantage.

Deliver working products frequently, from a
couple of weeks to a couple of months, with a
preference to the shorter timescale.

Business people and developers must work
together daily throughout the project.

Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done.

The most efficient and effective method of
conveying information to and within a development
team is face-to-face conversation.

Working product is the primary measure of progress.

Agile processes promote sustainable development.
The sponsors, developers, and users should be able
to maintain a constant pace indefinitely.

Continuous attention to technical excellence
and good design enhances agility.

Simplicity–the art of maximizing the amount
of work not done–is essential.

The best architectures, requirements, and designs
emerge from self-organizing teams.

At regular intervals, the team reflects on how
to become more effective, then tunes and adjusts
its behavior accordingly.

Okay, so there it is.  Yep, it’s that simple, I just changed the word “software” to “product”. Maybe you think there could be issues with some of these values or the principles if they were applied to other-than-software production.  I’d like to hear your thoughts.  If you have other industry experience, would these be good to apply to your industry?

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

New ScrumMaster Tips


I recently completed a blog on PMs transitioning to a ScrumMaster role.  I was inspired to put together a quick blog post for new ScrumMasters after reading a question that was posted to social media.  The poster basically wanted to know how to drive the team without them reporting to him/her or having “control” over them.  When I first read this I was perturbed but quickly thought to myself this person could be new to Agile and Scrum.  I’ll refer back to my definition of a ScrumMaster, a servant leader who is an Agile champion for your team.  I didn’t say management leader or controller or mother of dragons.

The ScrumMaster role is very challenging role and it takes some self control for people coming from a different role such as a PM or a lead from the team.  I am not a fan of “working” ScrumMasters, meaning they are also coders or leads.  They need to resist the urge to roll up their sleeves and dive in.  A good example of this, I was working on a Legos4Scrum (By Alexey Krivitsky) exercise acting as ScrumMaster.  Legos4Scrum is a cool way to introduce Scrum during an Agile bootcamp. You basically have teams working with sprints building items for a city while working with a product owner for vision of the city.  All the other teams had working ScrumMasters meaning they were diving in helping to build items such as schools and hotels for the city.  I was not building anything, instead I was separating the bricks, breaking bricks apart, sorting into colors etcetera making it easier for the team to build. Can you guess which team achieved a higher velocity? The team with a ScrumMaster who was constantly making the team’s job easier.  I was also working with product owner with any questions the team had as they were building. I tracked down the product owner if need be, not the team member working.  Do whatever you can to keep impediments down and efficiency high!

The servant leader side of the role is rewarding but being an Agile champion is crucial.  If you are new to the role start to soak up as much knowledge as you can.  At the end of the day you serve as the Agile coach for the team.  You should know the ceremonies and fun ways to facilitate them.  I highly recommend joining groups out there in internet land.  If you have a local Agile group join it, attend the meetings and share your experiences.  You will never stop learning.  Your knowledge and ways to handle situations builds trust with the team.

Another piece of advice I have is to provide a fun environment for your team.  Anything you can do to achieve this whether it is adding some cool posters or getting that energy drink fridge installed.  Try coming up with fun ways to do the standups and retrospectives.  If your team has the personality for it a prank doesn’t hurt from time to time.  Now remember don’t rewire the power switch on a PC to a remote power switch unless they can take a joke.  That was one of my favorite pranks I’ve ever been apart of.  Soft dart guns can also be very interesting on Friday afternoon.

I have only scratched the surface, this is a topic I could type for days on since I am very passionate about it.  That being said if you are a ScumMaster and have some tips please comment for those new ScrumMasters out there!

Posted in Agile Adoption, Agile Coaching, Agile Management, Agile Methodologies, Agile Project Management, Agile Teams, Scrum Development, Scrum Methodology | 1 Comment

What does it really mean to be an Agile Tester?

I was a QA Lead back in the mid 90’s for a couple of years, before any of this fancy Agile stuff really started taking off. Waterfall all the way back then; mostly manual testing, with full regression cycle at the end. Hurry up and wait, then go like hell given some ridiculously small window of time remaining before we had to release to Production. We started to dabble with automated testing tools, but they were difficult to use at the time; you almost needed to be a programmer. But a lot has changed since then.

What I learned more recently, in making the move to Agile testing methods and away from these more traditional QA functions, is that it’s a really big undertaking.

For those Testers out there who have yet to really dive into the deep end of the pool with Agile testing, let me just tell you this… you have never been so important in this new Agile world.

I think it’s this ‘whole team’ approach that’s probably the biggest difference between Agile and Traditional Waterfall development.

All for one

As an Agile Tester, you’re a full-fledged, first class member of the Agile Team. All for one and one for all!

You may be saying to yourself… “That sounds nice. And I don’t disagree on the Three Musketeers cheerleading you’re doing here, but I’ve heard that before. Be a bit more specific; What does it ‘really’ mean to be an Agile Tester?”

OK, allow me to elaborate…

For starters, it means that as an Agile Tester, you actively participate in planning, estimation, scheduling, retrospectives and any other activities of the team. You’re no longer in a QA silo where you only come out to play near the end of a project or release.

It also means you’re not the only one on the team who can test, anybody can. But no need for concern; you’re still the best equipped to do so. In other words, you’re job isn’t going anywhere. And more good news; you have help when you need it.

It means that you embrace change; you collaborate well with your team members as well as those outside the team.

It means you know how to help other folks on the team automate tests and help drive exploratory testing.

It means you put yourself in the customer’s shoes, and understand where they’re coming from, what their needs are. You’re empathetic, and can see the big picture.

It means you possess a unique perspective in the way things should work, and can help identify any potential roadblocks and dependencies sooner rather than later.

It means you guide other folks on the team, helping them improve upon their testing knowledge.

It means you work closely with the developers, sharing your skills and knowledge with each other; developers helping testers with some of the more technical aspects of creating automated tests, for example.

It means you work closely with the Product Owner, guiding and helping them understand the acceptance criteria, and final verification of what it means for a user story to be ‘done’.

It means you’re involved heavily in the design of the user story’s test cases prior to Sprint Planning. This helps your Sprint Planning Meetings go more smoothly. You groom your test cases in much the same way a Product Owner grooms their product backlog.

It means you’re an explorer. You’re systematic in the way you work, you pursue anomalies, and you think about what folks on both ends of the spectrum would do.

It means you radiate information. You open the doors and provide visibility into all testing activity. Things like ‘Testboards’ that display test status and progress, defects reports, impediments, trends, etc.

It means you’re heavily involved in the estimation process, helping folks understand the acceptance criteria for the user stories, and helping to refine them along the way.

It means you actively participate in Sprint Planning, identifying individual testing tasks. Things like preparing the testing data, executing the tests, exploratory testing, test automation, etc.

It means you help the Team decide what it means for a story to be ‘done’. Things like… code complete, unit tests written and executed, integration tested, performance tested, documentation completed, etc.

It means you understand and can articulate the difference between an ‘issue’ (a problem that occurs ‘during’ the Sprint and it coupled to a user story that hasn’t yet met its definition of done) and a ‘bug’ (identified ‘after’ a user story has been completed and accepted by the Product Owner). Bugs are included in and prioritized in the Product Backlog Item. Issues are not.

In particular, it means you understand the 2nd line item in the Agile Manifesto very well (working software over comprehensive documentation). Meaning you get the importance of face-to-face communication over formal documentation of all bugs. Be lean.

It means you address issues head on. We all know the sooner an issue is found, the cheaper it is to fix it. Make sure you practice this, and the folks on the team do too, and put it into practice.

It means you understand the importance of automation, and help the team put into practice stuff like automated testing, continuous integration, build-deploy automation, and continuous delivery.

And yes, it means you actually run tests too, whether they’re automated or manual.

Yea, I know; this is a lot to take on. Start small. Make progress in chunks. Be empirical. Inspect and adapt.

If you’ve made the move to Agile practices, what have you found to be the biggest difference when it comes to testing? What are some of your biggest struggles?

Posted in Agile Adoption, Agile Benefits, Agile Development, Agile Methodologies, Agile Project Management, Agile Software, Agile Teams, Agile Testing, Continuous Integration, Distributed Agile, Enterprise Agile, Iterative Development, Scaling Agile, Scrum Development, Scrum Methodology | Leave a comment

Agile Beyond Software: GM Case Study

Car EngineThere is an ongoing debate about whether Agile is just for software or if it can be extended to other industries.  I for one believe the Agile values and principles can be applied beyond software, but, in a recent discussion about this, a colleague raised a concern that some of the principles would be difficult to apply for some industries.  The principle in question: “Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.”

The thought here is that manufacturing industries have a high cost for changing once production has begun. This is true, it can be costly to change since production has to be stopped, parts changed, processes reconfigured, delivery would likely be delayed and there is cost in correcting any issues in products already produced.  However, one cost that is often dismissed is the cost of not changing.

Let’s consider the recent case with GM and the ignition switch malfunction.  According to several reports GM has issued a recall on about 2.6 million vehicles to repare the faulty ignition switch.  For arguments sake, let’s just pretend that the cost of the part and the cost to have a post production mechanic replace it is the same as the original.  That means for every replacement, they are paying double the original cost.  Then there are the costs for the accidents caused by the malfunctions, and the biggest cost, the cost of lost lives.  How do you put a price on that?

So, I think we can safely surmise that GM would have spent less money had they replaced the part when they found the issue.  What we should consider next then, is whether they could have replaced it, even late in development.  According to the graphic in this NBC article ( provided by Ronnie Polidoro, GM first found out about the issue in 2001.  Apparently they also dismissed a partial fix in 2005.  Now it’s 2014 and they have finally issued a recall.

It seems clear to me that, in this situation, accepting the change in requirements would have been easier and less costly than going with the chosen path.  It certainly seems that it would have at least been in the customer’s best interest to do so.

What are your thoughts?  Do you think Agile principles could be applied here?  How about Agile beyond software?  I look forward to your comments.

Posted in Agile Adoption, Agile Benefits, Agile Management, Agile Methodologies, Agile Project Management, Agile Software, Enterprise Agile, Lean, Scaling Agile, Uncategorized | Leave a comment

So you’re going to be a ScrumMaster?

Team“Well I am a PM now but they are making me a Scrum Master.” I have heard that statement countless times. Some PMs are happy about the new challenge, some aren’t and some just want to keep making those Benjamins. I have to admit even though being an embedded software engineer by trade the ScrumMaster role is my favorite role on a Scrum team. When asked what is a ScrumMaster I always respond with a servant leader and Agile champion for your team. Yes there are more details but I think simple is the best approach sometimes.

I thought it might be a nice time to talk about some of the qualities that a great PM has and how those look in an Agile environment. PMs tend to get a bad wrap from the Agile world so lets clear the air. I just so happen to have a fiancee that is a PM for a large company. She tries to give me a gantt chart for the week and I hand her story cards daily at breakfast. I asked her to take a survey of her peers which consisted of development, product management and other PMs. They came up with five qualities a PM has, here they are in no particular order.

Issue / Risk Assessment
Issue Resolution
Listening Skills
Manage Expectations of the Business
Process Oriented
On the topic of issue/risk assessment I can help your stress level by letting you know that issue assessment and risk assessment take different routes. Issue assessment gets the chance to happen everyday in team’s standup meeting. Of course if this is urgent it may be brought to your attention sooner. Risk assessment is happening all the time by way of the entire team. Is the sprint going to be completed, what stories might be slipping and what can we do as a team to deal with that.

Issue resolution is a key quality that will carry over. As a ScrumMaster you should do everything in your power to resolve issues or impediments for the team. This not only keeps the team adding value all the time it also builds their trust in you as the ScrumMaster. Issue resolution also requires a good listening skill.

Listening is a skill or quality that I think everyone is challenged with in life. Listening before you speak, listening before you start to think of your response etc. ScrumMasters have to fine tune this skill, even when it makes things uncomfortable at times. Some ScrumMasters tried to lead the team too often with words. I am a fan of posing the question and then letting the silence get uncomfortable enough that someone from the team answers. Which breaks the ice and conversation begins to flow. This also starts the baby step path to the team becoming more and more self organized.

Our next quality, managing expectations of the business, which is easier now! You get to manage it two weeks at a time or however long your sprints are. You will work with product owner to sprint plan and release plan if you are making use of that planning method. Better yet, let’s remove manage and add rank. Ranking is what a product owner is doing with the pieces of the value the business is looking for. Your job as a ScrumMaster may be to help the product owner provide details necessary to get the conversation and collaboration going! Those specs are you are used are gone and I challenge you to ensure the story doesn’t turn into a spec.

Being process oriented is good thing since you have new processes to learn. Scrum as a concept isn’t hard to understand but mastering it can take quite some time. That being said a Scrum team can take a year or more to fully mature. A good ScrumMaster is more than a certification, not to knock them. You will have times when you have to figure out the best way to passively guide the team towards better Agile values. You have to truly believe that what you are saying has value and can be successful.

So I go back to my definition, a servant leader and Agile champion. Live everyday for those around you and remember the values that Agile stands for. Go have fun with the rest of the pigs! (Search for it) I’m sure I didn’t paint rainbows and unicorns for the PMs out there reading this. I can assure you the ScrumMaster role will be one of the most challenging and enjoyable roles you’ve ever played on a team.

Posted in Agile Adoption, Agile Coaching, Agile Management, Agile Project Management, Agile Teams, Scrum Development, Scrum Methodology, Uncategorized | 9 Comments