Feed aggregator

Make Agile 2014 PEACHy

VersionOne Agile Management Blog -

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!”

Prepare
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

Engage
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 ReceptionIce 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+.

Adapt
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)

Collaborate
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.

Hangout
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.

What the World Cup and Agile Development Have in Common

Agile Connection -

There are a surprising number of similarities between successful World Cup and agile teams. Both must be diligent in four areas in order to reach their “goals.” This article explores the parallels between the two for selecting the team, getting up to speed, consistency, and game plans.

Avoiding the Organizational Death Spiral

Agile Connection -

The death spiral supersedes the death march in that the death march is a singular event, whereas the death spiral is systemic. It is the result of organizational dysfunction where teams march toward deadline after deadline without reflecting on or questioning if there is a better way to deliver software. There is! Take these positive steps.

Agile Software Needs Craftsmen

VersionOne Agile Management Blog -

So, 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.

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

VersionOne Agile Management Blog -

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.

Estimation First Aid from a Scrum Believer

Scrum Alliance -

This is the "first-aid kit" of my friend, who is an advanced consultant at a fast-growing IT consultancy. These are tips and tricks he discussed with me for helping teams that are struggling to deal with "time addiction."

With Me It’s All or Nuthin’

VersionOne Agile Management Blog -

Forgive me for bringing up show tunes.  I love the old musicals. One of the true classics of American theater 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 that 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, or 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.

 

Process Frameworks, Not Fixed Processes

Agile Connection -

The software development field has been consumed with process management ranging from inflexible, predictive waterfall all the way to self-governing, adaptable agile approaches. You probably already utilize a specific process methodology on your projects, but have you considered adopting an evolutionary learning cycle process framework instead?

An Experience Where Agile Approaches Helped

Agile Connection -

This article addresses a process where a team moved from a traditional waterfall model to using agile elements in order to deliver a product to a government agency. It talks about typical problems that come up in a transition to agile, complications from distributed teams, and the advantages and disadvantages of the process for government or nongovernment clients.

Are You Doing Portfolio Management, or Issuing Hunting Licenses?

Rally Software - Agile Blog -

Do you have a set of budgeting, funding, and approval processes so complex that nobody knows how they all work? Is the easiest way to get something done at your company to escalate to a senior executive, or go straight to a developer?

The other day, I was helping a customer untangle their approval/funding/budgeting processes. Now, this may not sound like the most delightful afternoon, but it was hot outside, and we were all ready to do it.

The company already has adopted some parts of SAFe -- they’re doing mid-range planning once per quarter in a big meeting, and getting better and better at delivering on those plans. But invariably, a half-dozen program managers and stakeholders would appear at those meetings wondering why their budget-approved projects weren’t in the backlog.

As it turned out, the budgeting and approval process was pretty Lean already -- but it was completely disconnected from PSI planning.

A small group of people was great at validating new business opportunities, rapidly exploring them, and deciding whether to fund them, all in a matter of hours or days. Once a project got approved, the project manager was then free to go off and try to get resources allocated -- either hiring people, or getting them reassigned, or just peeling off 20% of their time.  

This approach was a relic from the old waterfall ways of working. We’ve all seen these resource battles, and I realized on that hot afternoon that this wasn’t just a benign approval process.

Beware the Resource-management Jungle

This process was granting hunting licenses.

That is, project and program managers were heading out to figuratively hunt for people to enlist on their projects.

Are you doing this? Are you doing a careful job of approving work, only to send people off into a resource-management jungle armed with nothing but a budget, a business case, and a set of relationships?

If so, you might find that there’s a lot of wacky resource contention going on. You might even find people caught in the crossfire as project managers compete to capture their resources. (Is that the elusive senior engineer? Trap him in your team room! Promise him free lunches if he stays!)

Prioritize Your Backlog

So, what’s the alternative? It’s actually quite simple. The approval process has to feed into a backlog of initiatives. You’ve got to get your senior leaders to prioritize these initiatives based on your planned spend in different investment themes. This prioritization then feeds the backlog of work that goes into your mid-range planning meeting.

Then, when your teams actually plan out the work, you can see whether they’re actually working on your top priorities and adjust accordingly.

When you start your project depends on its priority, but it also depends on the number of initiatives you’re already working on (your WiP, or Work in Progress). Just because your initiative is approved doesn’t mean it should start right now.  

If the wait to start a new project is too long, that’s just a clear sign that you’re already working on too many things at once.

So your approval process shouldn’t grant a license to hunt resources. Project approval doesn’t mean you’re authorized starting the work immediately. It just means, “This thing seems like a good enough idea that we should prioritize it against all of our other opportunities.”

Modern Agile portfolio management suggests using the team as the resource unit. Read more about it here.

Alex Pukinskis

Lots of carryover? Try swarming

VersionOne Agile Management Blog -

Scrum 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.

Time enough for love.jpg

Alistair Cockburn -

Recent Change Note: http://www.vibrantnation.com/wp-content/uploads/110616031954_riot-couple616.jpg. What Heinlein might have used for the cover pic for his novel, "Time Enough for Love".

Pages

Subscribe to Torak - Agile Scrum Kanban Coaching Training Phoenix AZ aggregator