eROI has an interesting project they launched at http://eroi.com/ask-why. Here’s my first memorable Why Moment…
My first most memorable “why” moment was in the early 90s. I was a newly minted Development Manager on Norton AntiVirus and I attended a meeting early on where the Product Managers and the CEO had relegated NAV in to the “cow” category—it’ll make some money, but it’ll never be a $40M business; milk the revenue until it dries up as we shift resources away from it.
Brad Kingsbury, my boss at the time, and I asked “why?” To us the answer was obviously clear: it was a new market with too many tactical point products creating noise; each product being more of a feature than an actual solution. First real solution to market that both delighted customers and rolled up and surpassed the capabilities of the over 21 “one-offs” would be the winner—the solution needed to stand out with “Gee I’d Buy It Just For That” value props across the landscape and not just in a couple of areas. We went rogue, ignored the “cow” quadrant our product had been shoved in to, and built that solution. The rest is history… What was a $7M business when it was relegated to “cow” status grew to over $140M in a couple of years and is the foundation of what is a greater than $2B security business for Symantec today.
Moral of the story: Even propeller heads can and need to ask “why?”
Please share your own “why” moment either with eROI.com as part of their project or down below in the comments…
This will be my third post on doing short retrospectives at the end of each Agile iteration. My first was over a year ago, March of 2012, and my second was a follow up in July of 2012. Why this 3rd post? I’m just dumbfounded by all the teams I’ve met who have ignored this advice. Here it is a year later and had you picked just one thing, just one actionable thing, to do better with each sprint you’d have at least 17 process improvements under your team’s belt. Your team today would be able to reflect on how much has improved in just one short year. You’d feel just awesome about it.
If you’ve done this then congratulations! You and your team probably feel really great about how far you’ve come together. If you and your Agile team haven’t done this? I’m just speechless. Really?
Time for a short pop quiz: So, how did it go? Please classify your Agile Team in to one of these categories based on the last 12 months:
- Overachievers: 1 to 2 things per iteration to improve upon? Surely you jest! We found at least 3 things we could improve on per iteration, created action plans for each, and we can walk you through 50 or more process improvements since your post on this topic! We own the Agile!
- Achievers: We chose 1 to 2 things per iteration as you suggested, created action plans for each, and can share with you and other teams the 17 to 34 things we are doing differently to be a better performing team than we were twelve months ago.
- Hopefuls: We chose the 1 to 2 things, but really never acted on too many of them. We were too busy doing other things to actually improve ourselves. We have perhaps 10 things we improved upon in the year that has gone by. Thanks for the reminder and we’ll try to do better from now on.
- Embarrassed: Dang. We really didn’t bother to do anything with our retrospectives. We know that we should have, but we didn’t. Perhaps we can try again. Perhaps we can check in with other teams and see what they improved upon and see how we could possibly benefit from trying the same. We’ll make a fresh start and try again.
- Sleeping: Huh? Are we there yet?
- Contrarians: We see no value in any of this. We are the only Agile team doing it correctly. Your posts bore me. Why hold retrospectives? Why build our keep doing, start doing, stop doing lists? Why pick 1 to 2 actionable items from these lists to help ratchet up the performance of our team? Now go away, you bother me…
Now that you’ve scored your own team, what Agile Team do you want to be part of?
Go make it happen! Just take ownership and go make it so. Yes, you alone can make it happen. Don’t wait for your manager, the product owner, or scrum master to go do it for you; you go lead the charge to do it.
In these posts I can share my thoughts and advice, but I cannot do the work for you. Agile is about delighting customers while delivering incremental value; it is about weeding out what is holding your team back and embracing those things that help the team do better. As an Agile team you owe it to yourself to deliver some of that value back to yourselves; retrospectives can make that happen.
One last challenge: What improvements did your team identify and make in the last 12 months? Which are you most proud of? Please share them with others by adding them as a comment in response to this post. As I said before, we’re all in this together…
About this series: I love Agile; I also hate Agile. I love how it can free teams to truly delight customers while delivering high quality products on time. I hate how Agile zealots can use the Tower of Agile Babble to confuse the heck out of teams trying Agile on for size. My goal is to help new teams actually embrace and become Agile without having to learn all of the pomp and circumstance in one big fat swallow.
Today I visited Tualatin High this morning. I was very impressed yet saddened at the same time. While presenting Jill Hubbard with a $1500 check for being one of TechStart’s Educator of the Year grant award winners (she’s a rock star when it comes to STEM education) I learned the following about Tualatin High:
- It opened 20 years ago with close to 1000 students
- Today there are 1800 students and only 2 more educators than on opening day
- This year’s 7% budget cuts from the State will mean perhaps 17 educators will be cut for the the 2013-2014 term.
What’s wrong with this picture?
It is time for all of us in software and high-tech to do a full court press in terms of volunteering in our schools. The system is so broken that only we can fix it. Check out what one industry volunteer organizer has accomplished at Franklin High in just a couple of months in this TechStart Education Foundation March Newsletter.
Oregon Student Technologist of the Year
- A $2,000 one year scholarship to apply towards tuition and/or materials for a college computer science, information technology, or management information technology program of his or her choice.
- An offer for an internship with Cambia Health Solutions IT Department
- A $500 grant for the student’s educator to be directed towards the continuation and improvement of their classroom computer science / technology programs.
For more information, actual award and qualification details, and an application please go to http://www.techstart.org/studenttechnologist
Best,
-Mark
If I had a dime for each time a Fundamentalist Agilist told me that “In Agile you don’t do capacity planning” or “If you are doing Agile Team capacity planning then you are not doing Agile” or “Who cares about team capacity?! Iterate until you can ship; whenever that may be!” I’d be rich. These seem to be the same people who go nuts when I share that I’m fine with managers being scrum masters. Go figure… The good news, as with any extremist view, is that there are sane people in the middle that know better based on real world experience.
Truth be told, other than for some very trivial efforts that only ran a couple of sprints, I’ve never ever been involved with an Agile effort that didn’t involve some level of capacity planning. Never. I’ve also never met a successful R&D leader who hasn’t had to do this. When I look at some of these professional Agile “coaches” who shout out that “capacity planning is waterfall” in an effort to block or stonewall capacity planning, most haven’t worked on a team that had meaningful deliverables in the commercial marketplace or in IT after you pull away the layers of their bios or resumes. On the flip side when I ask folks who have really delivered true products under Agile I’ve found that all have had to look beyond the current sprint in flight and plan in some way for future sprint capacity. If they didn’t do it themselves, then somebody had done it for them. I felt vindicated in this view last week when I attended a dinner panel discussion put on jointly by the Technology Association of Oregon’s Developer’s Forum and the local PDMA chapter here in Portland. The entire topic was about capacity planning under Agile and the panel addressed this challenge head on.
The good news is Agile provides us a great framework and unparalleled transparency to do capacity planning like no other methodology. We know how many sprints fit between now and a fixed or desired end date, we know how many sprints we need on the back end for hardening, we know how many sprints we already have loaded with known work from our backlog, we know (or should be learning) the velocity of our Agile teams. What that leaves us with is a number of sprints left in the middle of this release cycle where an Agile team can take on new stories. Top down Agile planning allows us to look at those remaining sprints in the middle, look at the epics and/or stories we think we’ll see come over the transom (even though we may not know what they are today), and identify the pinch points in these sprints were we may require additional agile team capacity or may need to proactively push product owners to begin bumping stories out of our already planned sprints and in to the backlog for the next release.
Proactively solving for this capacity issue helps us identify how to prioritize and stage our projects as well as how to prioritize and staff additional agile capacity when we think we’ll need it. It also helps us land the plane and make our commitments. I know, “I’m doing it wrong.” I just don’t care: so are a lot of us with successful delivery track records over the years with Agile teams so I’m cool with it… As a purist you should be cool with it too if it works, right?
About this series: I love Agile; I also hate Agile. I love how it can free teams to truly delight customers while delivering high quality products on time. I hate how Agile zealots can use the Tower of Agile Babble to confuse the heck out of teams trying Agile on for size. My goal is to help new teams actually embrace and become Agile without having to learn all of the pomp and circumstance in one big fat swallow.
Once upon a time back in the 2000’s I joined a company and one of the teams that I had picked up had a very negative reputation with the business. The business viewed them as a bunch of slackers who acted like the company was a day spa and who could never be counted on to deliver anything on time. In fact, their latest endeavor was already nine months behind schedule and they had missed a few commitment resets to the business more than a couple of times before my arrival.
So, there I was the new head of R&D for this company and I walked in to a situation where the team had their latest deadline on Monday and here it was the Friday before. What were they doing? They were taking the afternoon off to celebrate by treating the entire team to a great steak lunch and activities. I naively thought that they must have finally finished. Boy was I wrong. As it turned out they knew that they were not going to complete on time. Not only were they going to miss their deadline yet again, but they hadn’t told anybody. They hadn’t even told me, the new head of their department. Not only were they celebrating a miss, they also had no intent of trying to put in any extra hours to honor their latest missed commitment to the business. Now call me the evil Californian who many native Oregonians sometime openly wish I would return with the rest of my lot, but really guys? Was this any way to run a railroad?
Since I couldn’t reach anybody that Friday afternoon I did a slow burn and built up quite a head of steam over the weekend. Although I was about as unglued as somebody could get I was able to come back down to Earth by the time I met with the manager on Monday about this latest miss. The answer that I got was “Well, we only need another 30 days and this team has been working so hard for so long that if we didn’t do something the morale was going to do a deep dive and we’d lose people.” Hmmm… I chose to ignore the working hard comment given that I had never witnessed that particular team put in half the hours that their peers on other teams were putting in on their own projects. Instead I stayed focus on the commitments being made and missed repeatedly.
“And how do you know you only need another 30 days?”
“Because there isn’t that much left to do.”
“Really? Can you show me your project plan? You’ve told the business this a few times before; given that track record you have no credibility and therefor I just don’t believe you.” (Note: this is before we rolled out Agile to the teams)
“Well, um, err, well, hmm…” was the response. I asked for the project plan. What I received the next day was an Excel spreadsheet that showed a couple of rows in work streams and a new milestone set 30 days out… It was an attempt to make a handful of rows in Excel look like an MS Project plan and if the file had been created before that very morning I would have been surprised…
So here was my problem… The team’s original committed date to the business was over 9 months ago and in the 3 months before my arrival they had asked for another 30 days no fewer than 3 times. This was the 5th time at bat with a new commitment. Seriously? Not on my watch…
Truth be told the team and the manager had no clue how much work was left. I drilled down on the new plan and found out that what was happening was that they thought they were almost done. Recommitting to anything further out than a month out seemed “way too long given how far [they’d] come”, but anything less than a month seemed “way too short as there was too much remaining ‘cleanup’ work to finish within 3 weeks.”
Wow… Mystery solved folks: Goldilocks was running the project and making business commitments. A new date more than a month out felt too far away and anything less than a month felt too short; therefore a full month felt just right.
Felt like the right answer a few times I guess. I hit the STOP button. I retrenched the entire team and had them create a real project plan. Two weeks later I was presented with something that was almost six months out. Wow… From “We only need another 30 days” to “We need another six months” and in less than two weeks of real planning no less… Had to be a record. Time to call Guinness Book of World Records.
After hearing this, and to add insult to injury, I just had to ask my favorite question of any project team. In my worst dumb Columbo impersonation possible (at least it was winter, I owned a trench coat, and I could place my fingers on my forehead as in forgetful attempts at remembrance). I asked “And if something goes wrong can you absorb the hit and still make this new commitment? Will this schedule survive a lightning strike?” Oh my… You would have thought that I really was the famous TV police detective and that I had just discovered the neighbor’s chopped up body parts stored in a barrel on their 2nd story balcony. Everybody had the same look on their faces and it told me they were still doing Happy Path “feels right” planning and there were even more rocks to turn over before this journey was over.
It was way past time to punt on this project; at least on my watch. I knew what I was working with and now understood what most of the major work items left were. After another week of working through the schedule and the QA plan I was able to make several updates. I also found there were several chunks of “rinse and repeat” tasks where even minimal QA automation could chop man-months off of the estimates. After some extensive work it looked like we could actually land the plane in 3 months and if we didn’t have any major screw-ups again we could come in early. The team executed on the plan and finally gave birth to their product. They had finally made their first commitment, albeit the 5th attempt well over a year late in the eyes of the business. Although the business didn’t care given the team’s history, I knew that with a couple of personnel changes, guidance, mentoring, and careful monitoring perhaps we could not repeat the sins of the past on future projects with this team.
Fast forward to today… Loaded Columbo question: So, even though your team claims to be Agile, does it suffer from Goldilocks planning and the resulting infection of 30 Day Syndrome?
One of the purported advantages of Agile is that you can ‘ship’ something at the end of every iteration. Yah, right… And the Pope is married with three kids (at least not in the last few centuries that is). For some teams it is true, especially for those with small efforts or very disconnected features with very few dependencies. The reality, however, is that in many commercial software endeavors as well as with large IT systems the complexity of the solutions and their often interdependent parts means that it really takes several iterations to complete anything that is shippable for mass use.
Some Agile teams, however, treat this as an excuse in terms of not making any commitments to the business. There are those who tell their business customer “I just don’t know and that’s okay as we are doing Agile; you should be okay with not knowing as well” or “It’ll ship when we have a Sprint finish and magically discover that there are no more stories left in the backlog; now go away as you bother me with your non-Agilist questions that I don’t have the time answer.” Then finally you have the teams that, when pushed hard for a date, reach back in to their inner Goldilocks hiding at the root of their brain stock and spit out the “feels just right…” answer. Yes, it often is 30 days out… Oh, and don’t let me forget the “end of the quarter” feels just right answer as well. Anytime I see the date of 12/31 I strongly suspect the team probably just threw the date out there as a “feels just right” placeholder (I’ve been wrong, but not often on that one).
I’m here to say, from experience, that if you were actually doing Agile, you would be able to name that tune plus/minus an iteration months out from your commitment date.
Okay, I’ll make it easier…
At the very least, any Agile team should be able to name their release date within a minimum of a 90 day window before that date.
We are only talking 3-6 iterations depending on your iteration length. There are commercial software teams out there who have to plan their iterations and their Scrum of Scrums to name that tune up to nine months out. Nine month is three times further out than what I’m saying should be the minimum.
It simply comes back to are you actually doing Agile or are you simply calling what you do Agile? If you were only working on groomed stories you’d be more productive and predictable. If you were doing estimates for your stories, and measuring how long it really takes, you’d be better story estimators. If you were better story estimators your velocity and burn down metrics would actually mean something and could be leveraged. If you had the historic velocity and burn down baselines to work with your Scrum of Scrum planning would actually mean something as well. If your Scrum of Scrums were working well you’d be able to actually estimate how many iterations are left in a given release. If you were holding real retrospectives with real actionable Keep/Stop/Start lists and were ratcheting up your team’s best practices with 1 or 2 incremental improvements each iteration you’d be a well-oiled machine with an amazingly predictable cadence.
But, for those teams who are not quite there with Agile, there is Goldilocks to fall back on. The problem though is that the business actually hates the story of The Three Bears and Goldilocks isn’t somebody they want to trust major business decisions to let alone to somebody they want running their project delivery teams. They want to trust these decisions to teams who are credible—those who make their commitments by delivering high quality solutions that delight them on time.
So, do you suffer from having Goldilocks as your inner Sherpa on this Agile journey?
Break free of this inner Goldilocks and start with the basics… Stories, acceptance criteria, planning poker, estimating stories and tracking the actuals, treating work as work (i.e. if it isn’t a groomed story in the backlog then it doesn’t exist), iterations where stories don’t move in and out like the changing tide, actually having retrospectives with a couple of actionable improvements each time at bat, having good Scrum planning, and taking Scrum of Scrums seriously.
I know it is a journey versus an event, but this isn’t something you wait for a manager to fix for you. It isn’t something you wait for the product owner or scrum master to do either. There is no room for whining or playing the victim on an Agile team. Rule one of digging holes is to quit digging; if you are helping to dig the hole then drop your shovel. There are successful Agile teams out there—copy what they are doing vs. waiting for somebody else to come in to solve the problem or fix it for you.
You are the master of your own Agile journey. Don’t be Goldilocks and suffer from your own 30 Day Syndrome when it comes to taking your own actionable steps to help adopt Agile.
If you are making commitments to the business, you cannot afford to be Goldilocks; they have no patience for it.
What’s your job description? I can tell you mine off the top of my head without thinking: Deliver high quality solutions on time and under budget that delight my customers. In fact, I would contend that should be the job description for any Agile Team member regardless of department, title, HR filed job description.
In my many years I cannot tell you how many developers that I’ve met who thought their job description was simply to “pump code”. These folks viewed themselves as artists on top of the technological food chain. If they were doing anything other than writing code then their precious time was being wasted. I know, I was one of these folks and that’s what I mistakenly thought early in my career. That said reality kicked in and I soon realized that writing code was simply a component of the job. I learned that to be successful that I had to pay equal attention to defect tracking and management, source code control, build management, release management, unit testing, and many other disciplines that actually helped me become a much better developer and allowed me to pump my own better code even faster.
I also witnessed something early in my career that made a huge impact on me that I thought I’d share. We had a developer on one of the teams who walked on water. He had the Midas Touch and could pump code like no other, making things work after many others had given up. When it came to critical path tasks he was always one of the guys always brought in to save the day by management.
He was also, pardon my French, an ass. He believed there was a caste system between developers, QA, support and other groups and that by sitting at the top of the food chain that all he had to do was pump code and everybody else could kiss his ring.
One day there was a huge yelling match out in the halls and I stepped out of my office to see what was going on (now I date myself…all developers at the time had individual offices so they could close the door and managers could shove pizza in the gap under the door; crazy, no?). A QA specialist had found a defect in this developer’s code and filled out an incident ticket and presented it to the developer. The developer was furious and was shouting in the hallways. He ranted and raved how stupid QA and others were for not finding the bug sooner. He wondered out loud how was he supposed to build great code if others who had job descriptions for testing that code were so bad at their jobs? In fact, he even bragged that he knew about the bug and was simply waiting to see how long it would take QA to find it. Since it had been there for months he stated that he was surrounded by idiots.
Finally a manager left her office, walked up, asked what was going on. She listened to the entire tirade again. Without blinking she asked one question very calmly: “So you knew about this defect and failed to enter it in to our defect tracking system as a test to see how good or bad our QA group is?” The rockstar senior developer gleamed with pride and replied “Yes.” Her reply was simple, short, and to the point: “You’re fired.”
Afterwards she pulled some rather dazed and confused folks together. Many were shell shocked as nobody had ever been fired like that before. Also, nobody ever thought that golden boy could be touched as he was one of the best coders out there and schedules were sure to be impacted as a result of his abrupt termination. She kept her words few, but on point when she explained what had happened and why she did it: “Our jobs are to delight customers with high quality products that are delivered in accordance with the commitments we’ve made; from this day forward throw your job descriptions in the trash. We are all on the same team. We all pull on the same rope together. If you agree you are welcome to stay; otherwise I’ll arrange for boxes.”
In the many years since, I’ve seen various versions of this job description log jam. On the other end of the spectrum I’ve even had QA leaders and staff who believed their jobs were to “stop products from shipping that had material defects that would greatly impact customers.” Sounds nice at first until you realize that what they are really doing is saving up some of the hardest tests until last such that they could hit the stop button a day or so before a release… As opposed to running those tests early and often and allowing those final days of testing to simply be smoke tests of what was already tested to ensure something materially didn’t break, they took pride in hitting the stop button and causing the entire team to have to retrench for days or even weeks. Instead of working proactively with the teams to ensure the gnarliest issues and gaps would be considered and covered by the teams early in the cycle they simply had a test plan in their folder for exposing the gap.
Although not as drastic and without a hallway of spectators I had to have the same discussion with them as a newly minted manager: “Your job is to ship high quality products on time that delight customers; testing something for the first time the day before release to prove a point in no way aligns with that job description.”
This is one of the reasons I love Agile. Job descriptions be damned. There are roles to play and if the role needs to be covered then somebody steps in to cover that role. Grab the story, move it to the in-progress column, and work it. Of course we try to cover what we know best, but we also jump in and cover what we don’t know or lend a hand to others when we have to.
We also don’t stay silo-ed within our own definitions while playing these roles. If you are a developer you can code until your heart’s content, but your job isn’t done until you know that code works before you check it in; if that means building test harnesses first, then so be it. Stories need acceptance criteria? Add them first and validate with the Product Owner. UAT test cases need to be checked out before UAT, then do them vs. waiting for UAT. Not written yet, help write them…
So, now that you’ve read this, regardless of your title or level, what is your job description?
