Showing posts with label Agile. Show all posts
Showing posts with label Agile. Show all posts

Thursday, June 12, 2014

"How the U.S. Military Prepared Me for Agile" (No, that's not a joke or oxymoronic statement...)

Scrum Alliance - How the U.S. Military Prepared Me for Agile

When I retired from the military at the ripe old age of 38, I had spent 4 years in the United States Marine Corps and 16 in the United States Army. As the retirement pay for a First Sergeant/E-8 with just over 20 years of service was not enough to fully support a family, I had to get another job -- and fast. At that time, I had an associate degree in computer programming, so I took a position as a full-time programmer trainee and went to college at night to get my bachelor's degree in software engineering. I had never really considered how my career in the military affected my civilian career until I started learning about Agile. Don't get me wrong; I knew that the military-instilled discipline and sense of honor and loyalty had made me not only a better man but also a better employee, but I had never really considered how my skills as a First Sergeant could have made me a better software engineer.

During my time in the military, I learned principles that mirror those I have seen in some of the common practices that several of the Agile frameworks/processes espouse. I would like to compare some of these practices with what I learned in the military. As you read, please keep in mind that I am coming from a combat arms unit -- mainly infantry -- perspective and that this perspective is based on the time I spent in the military (1971-1992). Things have changed dramatically since I was on active duty, so what was common practice then may no longer be in effect. I also understand that the Marine Corps has established a few doctrines that are somewhat based on the principles and practices of agility.

The first concept I want to address is organizational structure. ...





I believe Agile is like a multifaceted diamond. It takes a trained eye to spot all of its brilliant dimensions. But if you take the time to stare into it long enough, you will see that each angle reflects light differently. Remember, you are not here to "be" Agile like anyone else. You are here to "be" Agile like only you can be. You are unique. No one else has your experiences and your knowledge; they are yours and yours alone. My years in the military have enriched my Agile practice. I hope that this article spurs you to take some time to think about the principles of Agile and to consider how you may have used them in your day-to-day activities without even realizing it.

I appreciate the time you have taken to read this post, and I look forward to hearing from you.

Be safe."

As an Army vey myself, though only a Sargent, I can see where he's coming from...

Tuesday, May 20, 2014

Now this is a post title, "Teaching Relative Estimation by Throwing a Cat"

Scrum Alliance - Teaching Relative Estimation by Throwing a Cat

A quick and fun exercise that will help you teach relative estimation

I'm a big fan of relative measurements in software development. However, when teaching this idea, I've noticed that many developers who are used to estimating work in hours or days find it difficult to switch to using story points as the relative measurement of complexity. Many times I've heard comments like, "We use story points -- and one point is eight hours."

Old habits die hard
It's always challenging to learn a new habit and break an old one. Therefore I was constantly looking for a good exercise for my Scrum training that would let people compare work items without calculating effort. The ideal solution should be quick, usable with Planning Poker, and -- most important -- fun.
Hans Solo's Millennium Falcon and Mike Cohn's dog and zoo points


Throwing the cat -- what you should expect?

Things always get most interesting when you end your list with the cat from the title of this article. (If you have an avid cat lover in your audience, you might opt for a squirrel instead.)  ...


You might be wondering why we don't estimate how far you can throw objects. The reason is twofold. First of all, distance describes an effect -- the business value of throwing, not the complexity. And second, it's one-dimensional, so people can switch back to the unit measurement, where one point equals one meter.

Now when a family member asks how your day was, you can say, "We had a heated discussion at the office about throwing a cat!" Be sure to have fun -- and if you've enjoyed this exercise, let me know!


Really, I just loved the post title.. :)

Monday, May 12, 2014

How does Microsoft scale Agile? Here's how, all in a very cool looking webzine

Visual Studio - Engineering Stories 


Welcome to our new Engineering Stories site. This is a place for us to share how we build software at Microsoft. Today, we're releasing our first story describing how we adopted and scaled agile practices across Developer Division. It's a story describing our journey towards a faster release cadence, a more engaging engineering process, and, in the end... a better product. I hope you find these stories useful and engaging. Our goal is to share where we've found success, and also where we've struggled. Let us know what you think.


Scaling Agile Across the Enterprise

A little history

You might remember how we made software a decade ago – "we" being the entire software industry, Microsoft included. By today's standards, slow ... as ... molasses.

We released products on two to three year cycles. It wasn't unheard of to spend six months to a year planning, a year or more coding, and then months packaging everything up for delivery. It worked in the software generation in which it was born, but today's environment requires a different approach. Today we buy software daily—often with just the touch of a finger on the device we're carrying with us. Market opportunities come and go more quickly, and customers demand increasingly faster turnaround to meet their needs.



I heard about the Microsoft DevDiv move toward agile at the 2012 Build and thought it could dramatically change the way we see software coming out Microsoft (or be a total bust). I can't say if it was indeed this move, but even the biggest hater has to admit, the software release cadence we're now seeing it nothing less than amazing, compared to just 5, heck 3, years ago. And the scary, in a good way, is that it looks like its speeding up!

Thursday, February 06, 2014

"Grumpy, Descartes, Mr. Bighead, and Mr. Blasé" and your move to Agile...

Scrum Alliance - Grumpy, Descartes, Mr. Bighead, and Mr. Blasé

Anybody who has had to direct any form of change in an organization must have come to realize how it is about people. This has been recognized for a long time and documented extensively (see

In particular, there always seem to be some people who will resist and make it difficult.

In a report about the Agile transition at Yahoo!, Gabrielle Benefield writes, "Not everyone is willing or able to change." She also states that "10 to 15 percent of people will not like the status quo at any given time" (see "Rolling out Agile in a Large Enterprise"). And I think I can confirm this statement from my own personal experience.

So lately I've been wondering: Is there a typical profile for those people who have a hard time transitioning to Agile? Are they always the same from one organization to another? Is there a magic formula to spot them right away?

After some time trying to describe the typical profile, I recognized not one but four distinct profiles. Here's how to recognize them, and some tips to help get them on board with Agile.



Which one of these guys are you?

None, right! But you've worked with some I bet. This article has a some good tips on how to help handle them in your move to Agile...

Tuesday, December 10, 2013

Bingo! Your BS Bingo Cards for about every occasion

Agile ScoutBulls*t Bingo Scaled Agile Framework


Before each daily scrum, visit Scaled Agile Framework (SAFe) Bingo and print one copy of this game card for each player,refreshing the page before each print, or have the players print their own bingo cards. These instructions will not be printed. You can also select an embeddable card only version of the game or a multiple card version of the game when playing on line, or with a smart phone.

Check off each block when you hear these words during the daily scrum...

Bullshit Bingo Game!


Software Development Bingo!

Before each meeting or conference call, visit Software Development Bingo and print one copy of this game card for each player, refreshing the page before each print, or have the players print their own bingo cards. These instructions will not be printed. You can also select an embeddable card only version of the game or a multiple card version of the game when playing on line, or with a smart phone.

Check off each block when you hear these words during the meeting or conference call. When you get five blocks horizontally, vertically, or diagonally, stand up and shout "BULLSHIT!!!". Or play as a drinking game and for every block you mark off, take a sip, and finish your drink each time you get five blocks in a row


I didn't see a "Yearly Budget Planning Bingo" card... must work on that.  :P

Thursday, September 26, 2013

"The Ultimate Agile Planning Handbook" Free [email address-ware] eBook from Telerik

Telerik - The Ultimate Agile Planning Handbook


Stay on top of your backlog and manage your iterations like an Agile guru with the help of our Ultimate Agile Planning Handbook. Dive into this 20-page whitepaper with how-to tips and important Agile planning best practices that will help you improve your processes today. Some of the areas we address are:

  • Time boxing
  • Optimizing iterations
  • Prioritizing and sizing the backlog
  • Using uncertainty and maturity to improve prioritization
  • Improving predictions using velocity and capacity and more
  • Most common challenges related to planning and how to overcome them

Start transforming your planning process today!

This looks to be a "manager safe" short little eBook.

Here's a snap of it;


(via Tatworth - Free book from Telerik - The Ultimate Agile Planning Handbook)

Tuesday, August 27, 2013

Featuring Agile Planning and Portfolio Management with TFS2013 in these Hands On Labs

Brian Keller - New Lab: Agile Planning and Portfolio Management with Team Foundation Server 2013

When we shipped the Visual Studio 2013 ALM Virtual Machine earlier this month we were still in the process of finalizing one of the hands-on-labs / demo scripts. This work is done and you can now access Agile Planning and Portfolio Management with Team Foundation Server 2013.

If you are not yet familiar with the agile planning tools introduced in Team Foundation Server 2012, you should start with Exercise 1 of this lab. In this exercise you will learn how these tools can be used to help a small team manage their backlog, break work down into iterations, and track this work using a task board.

Exercise 2 introduces the new agile portfolio management capabilities introduced in Team Foundation Server 2013. These capabilities allow you to “scale agile” across your entire organization by providing you with a hierarchy for your backlog. This means that I can have several smaller teams sprinting together to achieve related objectives, and I can track that work in either a top-down or bottom-up manner.

Finally, Exercise 3 will show you a few of the ways that Team Foundation Server 2013 allows individual teams to maintain some autonomy in the way they work without requiring core process template changes on the shared team project that you might be using across the entire organization. Features such as the Kanban board and work item tags can be customized on a per-team basis to adapt to the individual needs of those teams.

image[GD: Post Leached in Full...]

Nice way for you to see and start getting comfortable the new features coming in VS/TFS 2013 as it related to planning and management...


Related Past Post XRef:
Visual Studio 2013 ALM and HOL VM now available...
Playing with SQL Server 2014 (and VS2013) the Azure VM way
VS2012 Update 1 ALM VM and HOL / Demo Scripts now available
The VS 2012 ALM Virtual Machine and VS 2012 Update 1 (In short, there's an updated VM coming, don't install it on this VM if you don't have too)
The big BK has updated the Visual Studio 2012 RC ALM Virtual Machine and Hands-on-Labs
VS 11 ALM DemoMates updated for the Beta
Visual Studio/TFS11 ALM Demo's... Mate! See the VS/TFS 11 ALM's hands-on-labs in DemoMate form
Visual Studio 11 ALM VHD's, VirtualBoxed (and even on x86 hosts too)
Want to play with Visual Studio 11 & TFS 11 Dev Preview but don't want to install it (and have access to a Hyper-V server)? Here's a VHD just for

Wednesday, July 17, 2013

Silos are for farms, not agile development teams...

naked ALM - A better way than staggered iterations for delivery

There is a better way than staggered iterations for delivery that will keep you on the path to agility.

I have seen many companies that are trying to move towards greater agility get trapped in the past by creating artificial silos based on skills. They believe that by creating a timebox for planning, development and testing that we can get closer to agility and move away from our traditional models. Unfortunately the actual result is to enshrine that traditional staged model and step sideways on the path to agility, not forwards. In many cases it can be a significant step backward that will take many painful years to rectify.



The problem with staggered iterations for delivery

In the diagram above we have an 18 week cycle from inception to delivery. That’s more than 4 months between ideation and delivery with a lag of 2 months to even get feedback with a 2 month lag for all subsequent feedback. Worse this is the most expensive kind of feedback as the Coding and Testing teams ..


The solutions to staggered iterations for delivery

We need to foster teams over individuals and make those teams responsible for the delivery of working software. To get that we need cross-functional teams that can turn ideas into that working software. And we need to do it often.

  • Cross-functional teams –We need to have...
  • Asynchronous development -  Ideally you want...
  • Test first – Test first is about not doing any work unless there is a measurable test that ...
  • Working software each iteration – If you don’t create working software at the end ...
  • Quality Assurance requires no testing – If you consider that all testing is done as part of the sprint, ...



The expected result of staggered iterations would be an increase in rework and in technical debt. If you are moving from a 4 year iterative process to a 4 month one you will see value, but your process will be opaque and will only reduce your ability to deliver working software.

Yes your cycle time will be reduced, but you can do so much better....

I've been here, done that, but I've found that without support and buy-in by everyone, this is an easy trap to fall into. Heck even cross functional teams can be a political beast that can't be slain, let alone everything else.

Yet, that doesn't mean we can't dream and strive for something like this.

Thursday, April 04, 2013

Scrum Primer, the v2...

Scrum Alliance - The Scrum Primer

The Scrum Primer is an in-depth introduction to the theory and practice of Scrum, and includes data on results from a large-scale corporate adoption of Scrum. Its authors are Certified Scrum Trainers Gabrielle Benefield, Pete Deemer, Craig Larman, and Bas Vodde.

You can download the Scrum Primer here.

Scrum Primer


Scrum Primer  - About

Scrum Primer Creation

Scrum Primer was originally created by Pete Deemer and Gabrielle Benefield when they were both working in Yahoo! on their agile transition. When Craig Larman and Bas Vodde were working on their first Scaling Scrum book, they wanted to use a good introduction of Scrum as a reference but didn't want to write a new one. They joined forces with Pete and Gabrielle and all together rewrote the Scrum Primer.

The Scrum Primer 2.0 version was created for InfoQ and for being more consistent with the latest descriptions of Scrum.

What's a Scrum blog post without the a Scrum picture?


Here's a page thumbnail snip;


Based on the PDF document metadata, this guide looks very fresh, created 4/1/2013... [insert April Fools joke here]

Wednesday, December 05, 2012

Delivery and Deployment is a feature... "Agile Program Management: How Will You Deliver?"

Managing Product Development - Agile Program Management: How Will You Deliver?

One of my program management clients is organizing a program and is having trouble thinking about a delivery model that fits their program. They are transitioning to agile and are accustomed to traditional releases. When I suggested they have someone representing deployment on their core team, that was an initial shock to their system, and now they see that it was a good idea. They don’t have a hardware person on their core team, but otherwise they look a lot this this picture.


Core Program Team

With agile, they have options they didn’t have before. Because they are a software-only product, they have the option to release as mandated release as before. They can rollout as before, with IT scheduling the release and mandating when people upgrade. I asked how well that worked before. You should have seen people’s eyes roll when I asked that question!

I suggested there might be other options: continuous deployment and phased deployment. ...

What clear to me, is that if you want to be agile in your program, you need to think about delivery and deployment as soon as you start your program management work. How you deliver and release is critical. Once you know your release criteria, you need to know how you will release. There is no right or wrong decision. It’s a decision for your program.

I've seen this as well, where there's little thought in the "Agile" project development about delivery and deployment. "It's not our problem once we deliver it to IT. 'They' will deployment whenever..." (No kidding). Deployment is a feature and those involved in it need to be part of the team. We're all one happy company, right? :/