Austin Agile

Recap of LSSC12 Conference

2012-05-17T15:22:00.000-05:00

I just returned from the Lean Software and Systems conference in Boston. There was a definite common thread around learning cultures and a focus on treating our industry as a set of scientific experiments. The heavy influence from the Lean Startup movement was prevalent. Here are some of my takeaways for those that were not able to attend.

Steven Spear

Greatness is achieved by increasing the pace of learning

David Anderson

Kanban Principles

Start with what you do now
Agree to pursue incremental evolutionary change
Initially respect current roles responsibilities and job titles
Encourage acts of leadership at all levels from individual contributor to senior management

Implement feedback mechanisms added
Steps for converting to Kanban

Understand sources of dissatisfaction

From viewpoint of internal and external
Source of variability that cause dissatisfaction

Demand and capability analysis

By work item type and class of service

Model workflow

Understand the knowledge discovery process by type

Kanban system design
Visualization
Roll out plan

Steven Denning

Dude’s Law - David Hussman

Value - Why/How
Focus on the Outcome

The only valid purpose of a firm is to create a customer

Not create shareholder value

Switch your focus from Outputs to Outcomes
Customer Delight = Providing a continuous stream of value to customers and delivering it sooner
The goal is to delight the customer. Everything else is a means to getting there

Less is more. Aim for the simplest thing.

Costs will come down because you will only focus on things that delight your customer

Commands kill conversation

Money kills inspiration

Dominica DeGrandis - Kanban for IT Operations

Need to get visibility to dependencies because they carry risk

Design your SLA’s into your board. Create timeline like tick marks across your in progress column and move items each day.
Problems with board where there are names for swimlanes

Standups are focused on individuals
Perception of poor performance
Limits Collaboration
Focus on utilization
Pigeon hole folks

Bring visibility to skill levels of different skills required on team
Make interrupts visible
Institute the Goalie.

Handles small interrupts
Rotates Weekly
Expands Knowledge base
Gain flexibility in team

Make a policy on when the team should create a ticket for something (i.e. takes more than 4 hours)

Jeff Patton

Focus on Value
Don’t focus on maximizing the output, focus on maximizing the impact of the outcomes
Think beyond the edges of the Kanban board

Arne Roock and Markus Andrezak

“Projects” are like waterfall containers that have planning, time constraints, focus, budget and purpose
Replace projects with epics that align to strategic goal/ outcomes. Let the team work to achieve those outcomes

Don Reinertsen

Compared Software to Firefighting, “You don’t just say this is a complex adaptive problem so we can’t create a plan”

Jim Benson

Change happens in evolutionary leaps
Kaizen is a status quo monster

Misc

Can run simulations through board http://www.focusedobjective.com/
“Standard” is just the status quo written down

Some of the presentations:

Infrastructure Agility

2012-05-17T13:28:00.000-05:00

Infrastructure Agility

Whether your team is agile, lean, or anything else you have likely run into frustrations with your infrastructure. See if any of the following strike a chord with you:

You aren’t sure how your servers are configured
Your servers, workstations, etc. aren’t configured the same way
Nobody is sure who changed a configuration file, or why, and what was the last good version of the file?
Who installed that rogue server process? Why was our standard version of a dependency upgraded that is now breaking our applications?
Why are our development servers configured differently than our QA servers? What will it take to make them the same?
How long will it take to upgrade or install application x on our cluster of servers?
Your developers/QA/UAT Testers are blocked 3 days waiting on ops to install/upgrade a server with something new needed for a story
It takes 3 days for new developers to get set up with all the standard dependencies (or the machine image used has old/missing versions and needs a lot of upgrading)

No matter what your particular frustration, your infrastructure and systems take time and effort. We see it all the time, but it is especially frustrating when teams following lean/agile principles who have put effort into eliminating waste and providing quick feedback find themselves against another wall they must continually climb and are regularly slowed.

Getting Control of Infrastructure

We don’t advocate solving a problem you don’t have, so if frustrations like those mentioned above are not among the bigger problems affecting you, just file this away for later.. But for many of you the above probably resonates.

So, where do you start?

Outsource It!

First, why not just fix the glitch? Why spend time trying to address a problem you can get rid of? Look at your application, infrastructure, whatever that is causing you pain. Is it standardized enough that you can just offload the problem?

We don’t want to just move the problem to a team doing the same thing in another location. What I’m referring to is taking advantage of platforms that have taken common deployment or infrastructure scenarios and packaged the operations around them as a service. You do this when you choose to host a server on a cloud service like [Amazon] or [RackSpace]. This kind of cloud computing model which abstracts and automates the details of physical hosting of storage and computing resources is often referred to as Infrastructure as as Service, or IaaS.

You can take this to another level by using a service like Heroku or AppFog that removes the need to manage servers and instead deploy to more highly managed environments that accomodate certain solution stacks. If your application fits their managed platform or isn’t too customized you can avoid having to deploy both servers and much of your solution stack, focusing on your core application code and configuration. This level of cloud computing services is often referred to as Platform as a Service or PaaS.

Offloading what you can offers you reduced complexity of operations for some or all of your environments. But for many teams we have found constraints that don’t allow taking advantage of these types of services.

Control It!

Whether you have resources in the public cloud, private clouds, or on good old bare metal hardware, you have work to do to manage provisioning, configuration, deployment, and tracking of assets and infrastructure.

Agility in infrastructure is achieved through:

Providing good visiblity on the infrastructure you have
Eliminating bottlenecks to adding / changing your environments
Minimizing complexity
Being able to adapt quickly to changing business needs
Having a high level of communication and visibility across all those involved in delivering software to end users

Many operations teams already track assets in various places. Some keep standard configuration files and checklists they use for consistency. Others have scripted common tasks in their daily operations work. But not all do these sorts of things. And even if they do, manual work ends up being the biggest bottleneck of all. The path to agility requires finding straightforward, consistent ways to communicate, control, and automate your infrastructure management.

Infrastructure as Code

While not necessarily new, there has been some disruptive change in recent years led by the growing popularity of tools like Chef and Puppet. Similar tools, such as CFEngine have been around much longer in different incarnations both inspiring the newer generation of tools and greatly evolving in their own ways. The combination of these types of tools with the rapidly expanding selection of virtualization and cloud tools.

The philosophy is simple, with the support of the right tools a team can create configuration files and scripts (code) that describe what their infrastrcuture should look like and how to go about creating it. This code can be executed to provision systems, configure and install dependencies, deploy applications, take inventory of what is deployed, and keep things consistent.

As Jesse Robins once described, the goal is to:

Enable the reconstruction of the business from nothing but a source code repository, an application data backup, and bare metal resources.

Such an approach to managing insfrastructure isn’t limited to servers either. Some groups use it to help keep developer, tester, or other types of desktop machines up to date with the latest tools/configuration a team needs. When you have only a few machines to manage such an approach is neat. When you have hundreds or thousands it becomes essential.

Hopefully this has piqued your interest or brought awareness to how we include infrastructure in our assessment of agility and waste. As always, don’t solve a problem you don’t have. But if infrastructure issues are affecting your team and you have identified the bottlenecks stay aware of your options.

We will follow up with additional posts in this series on Infrastructure Agility with looks at DevOps and a closer look at tools like Chef and Puppet.

A Tried and True Method for Retrospectives

2012-05-10T12:02:00.000-05:00

I feel the Retrospective is the most important ceremony, especially for new teams. I am concerned when ScrumMasters boast they can get their Retrospective done in 30 minutes or less. I must ask, “Did your team learn anything? Are they improving? Are they pushing themselves through the Tuckman Model and getting close to becoming a High Performing Team?”

In my experience, new teams need 1.5 - 2 hours for a healthy retrospective. They need time to reflect on the Sprint and fully explore opportunities for improvement. The retrospective is a key ingredient in engaging teams to take ownership of their own process and figuring out how to improve. In this post, I will walk through my standard approach to a Retrospective.

Goal

It is easy for the team to identify a laundry list of problems, but the team can’t address more than a couple at a time. The goal is to devise 1-3 actionable items the team can change during the next Sprint timeframe. If the team can make a 2% average improvement every two weeks, they would accomplish over 50% improvement on the year. In order to encourage more significant improvements, we also need to help the team have the courage to try some more radical changes.

Set the Tone

When I kick off a retrospective, I want to make sure it is a safe room for the Team. This includes the team members (Pigs), ScrumMaster and Product Owner, but does not include chickens, stakeholders or managers. We also want to defuse negativity. I usually kick things off with a statement like the following:

“We are looking for changes that we the team can change. This is not a blamestorming session (I usually point with my fingers outside the room), this is a chance for us to reflect on what we (pointing at myself) can do better as a team.”

I might also put the Norm Kerth quote up if I think there might be some attacking of individuals:

“Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.”

When setting the tone, I also like to share our current metrics. Things like:

The Sprint Burndown

Sprint Results (Points planned vs. completed)

Release Burnup to show progress on overall goal

This helps the team review some of the facts around their performance and effectiveness.

Data Collection

The next thing to do is gather some data and insights on the Sprint. The standard way to do this is Start, Stop, Continue. I create three sections on the wall or whiteboard with those titles and have the team come up with as many items as they can in 5-10 minutes. We are looking for:

Things that worked well and the team should Continue

Things that did not work well and the team should Stop

Things that the team did not do and should Start

This exercise should be silent with folks writing individually. This tends to prevent a couple voices from dominating the discussion and get the introverts to participate a little bit more. We want to give the team members time to reflect to themselves on opportunities for improvement and reinforcement.

They should all be writing at the same time with provided Sharpies and Post-it notes. They should write one item per Post-it, which can be put on the wall anytime. Sometimes, the early ones will help others generate ideas, but this is all done silently. The Sharpies are important so that everyone in the room can see what is written on the Post-it. Once I see that no new ideas are being generated, I move on to the next step.

Read for Clarity

I introduce this step by saying:

“Now we want to read through the items to get an understanding of what everyone has written. On this first pass, we just want clarity so we don’t want to get into discussion or debate. If you are unclear of the meaning of what someone wrote, just ask and that person can provide a brief description of their intent and then we will move on to the next item. Now who can come up and read one of the columns?”

I have volunteers from the team read the items to foster ownership by the team. As the facilitator, make sure the volunteer is reading slowly enough so participants have enough time to digest. If after a couple have been read and no one has asked to clarify, I typically will ask for one to be clarified so people recognize it is ok to interrupt. Once they have finished one column, I thank them and ask for another volunteer until all three columns are read.

Group and Theme

In the next phase, we will organize what we have to determine where to focus our discussion because there is rarely time to discuss everything.

I ask everyone, or for large teams everyone who did not volunteer to read a column, to stand up and go to the board. At the board, we want everyone to do a silent sort (for speed). They should put like items near each other (without covering up the others). At this stage, it is ok for items to move across columns. Once they have a grouping, they should label the themes. It is ok to have a couple oddballs that don’t fit into the groups.

Prioritize

If you have 3 or less core themes, focus on those and start with the one with the most items. If you have more, then you need to prioritize. I like to use dot voting. I give each person 3 dots (Stickers) and ask them to vote on the topics they think are the most important to tackle. They can put all three on one item or spread them across multiple. They are voting for a theme not individual items. (Hint: ask them to place them on the Post-it as it is much more difficult to peel them off of the whiteboard or wall.)

Discuss

Based on the voting pick the top 3 items and set a timebox of about 15 minutes per item. Ask an open ended question on the topic and then let the team own the discussion. (i.e. “So what do you guys see as the underlying problem here?”) As the facilitator, try and refrain from leading this discussion. We want the team to drive it and it is ok for the discussion to wander a bit. After 5-10 minutes, try and bring it to a close with something actionable the team can change. Prompt them into solutioning by asking something like, “So what can we as a team do about this?”

Take Action

Make sure the team comes up with actionable changes, i.e. SMART goals. Ensure the team discusses how they are going to make it happen. Create immediate tasks in the Sprint Planning session that should follow. Make the goals visible and part of the plan, i.e. put them on the task board.

Other Variations

Don’t let it get stale. Try different things. I recommend buying Esther Derby’s book (listed below) to help generate new ideas to keep your team engaged.
Other favorites: Speed Boat (Innovation Games), Triple Nickles (Esther), Mad/ Sad/ Glad (Esther)
Sometimes just have a conversation as a team
Occasionally just focus on a team building exercise
The problems aren’t always clear and you will need to do some root cause analysis. Some great tools for that are a Fishbone and the Five Why’s.
It is ok for the ScrumMaster to set a focus topic of the retro. i.e. Let’s focus on self-organization or being releasable at the end of the sprint
For Release Retrospectives I like to do the Timeline (Esther) exercise or Remember the Future (Innovation Games)

References

Agile Retrospectives: Making Good Teams Great, Esther Derby & Diana Larsen
http://innovationgames.com/

Announcing Agile-Lean & Kanban Foundations Class Aug. 1st

2012-04-26T15:09:00.000-05:00

Agile-Lean & Kanban Foundations introduces Lean and explores its relationship to Agile Software Development. The class will look at Kanban as a Lean approach to incremental, evolutionary process and systems change for organizations and how it can be used to develop software according to the values and principles of Agile.

Conducted by Agile Velocity.

Location NW Austin TBD

The first 5 registrants will receive a $100 discount.

http://agilevelocity_kanban.eventbrite.com/

Class Highlights:

Introduction - Agile foundations
Lean concepts
Kanban concepts
Agile teams and roles
Planning
Requirements
Estimation
Best practices
Continuous integration
Interactive exercises throughout the workshop
Onsite lunch will be provided
Q&A

Who Should Attend?

Engineering Managers and Team Leads, Developers, QA Engineers, Product Managers, Scrum Masters, Product Owners, Business Analysts, Program Managers, Information Architects, Executive Management with oversight responsibility, and anyone interested in incorporating Lean or Kanban practices into an Agile development process.

Kanban vs. Scrum – How to Choose?

2012-02-01T22:33:00.000-06:00

Kanban vs. Scrum – How to Choose?

My clients frequently ask me when to use Kanban and when they should use Scrum. To form a recommendation, these are some of the questions I ask:

Do your priorities change often? Do you have trouble locking scope for 1-2 weeks at a time? Do you have more than 25% scope churn during a 2 week period?

If you answered yes to these questions, score 1 for Kanban. By dropping the fixed timebox, it will allow your team to adapt more easily to the quickly changing priorities of your business.

Do your teams struggle to break features into incremental pieces of value to be delivered in less than a week?

If you answered yes, score 1 for Scrum. Both frameworks work best when you break your work down into small incremental pieces. I find the Scrum Sprint timebox can help teams new to the practice recognize their deficiency (work not completed at the end of the sprint) and adapt (retrospective).

Do your teams struggle with estimation or question its value / overhead? Can they break work down to reasonably small, similarly sized chunks?

If yes to these, score 1 for Kanban. Kanban removes the overhead of estimation in favor of measuring cycle time for like sized items.

Do your teams have a strong culture of continuous improvement and self-organization?

If so, score 1 for Kanban. The lightweight framework that Kanban provides works very well in a culture of continuous improvement. They will know the right times to hold a retrospective. For teams new to this practice, the regular cadence of a retrospective ceremony will help teams establish this practice.

Are your teams highly disciplined with technical practices and craftsmanship, such as TDD, Continuous Integration/ Delivery, Shared Ownership, etc.?

If you answered yes, score 1 for Kanban. Note that both frameworks excel in an environment of strong technical practices. However, a Kanban team may be able to reach a higher optimization level by having a constant flow of work.

Is your team's top priority to optimize responsiveness to customer needs?

If so, score 1 for Kanban. Kanban has a strong focus on cycle time, where Scrum has a stronger focus on Velocity. Both can be tuned to provide very similar output, but Kanban has the flexibility to lower batch size to reduce cycle time at the potential cost of productivity.

Is your team's top priority to focus on predictability and productivity for larger projects?

If so, score 1 for Scrum. Again, you can achieve predictability and high level of productivity under both frameworks. For new teams, Scrum provides more guidance and resources of how to handle release planning and progress tracking.

What is the appetite for your team for process change?

If low, then score 1 for Kanban. Kanban has a lower level of Ceremony and may be easier to incrementally introduce into your organization.

Does your organization/ culture demand a higher degree of ceremony and artifact?

If so, score 1 for Scrum. Not that Scrum has a high level of ceremony in comparison to methodologies such as RUP, PMBOK, and PRINCE2, but it can integrate well into a culture requiring more documentation. From a Lean perspective we would question the need for this potential waste. The reality is that sometimes we have to fit within a certain culture and incrementally work ourselves out of it.

Summary

Both Kanban and Scrum require strong discipline to do well. Kanban doesn't have as many rules which is good, but it also can be taken advantage of by an undisciplined team. Both can be abused: Scrum teams could constantly carryover unfinished work or Kanban teams could ignore WIP limits. Scrum's Sprint time box or Kanban’s WIP Limit should force teams to figure out how to break things down into smaller pieces.

I see teams most successful with Kanban fit into two areas:

1. Support the business teams - These teams are focused on serving the business to keep the software running. Their priorities can change on a daily basis with frequent delivery of software. These teams need to optimize to be ultra-responsive. Kanban can enable these teams to optimize flow.

2. Mature, disciplined, self-organizing teams. They are engaged in the process, understand how to break down work and are constantly swarming to get things done.

Where do you see one fit best over the other?

David Hawks is an Agile Coach and Trainer based in Austin, TX who helps organizations transition to Agile by implementing either Scrum or Kanban.

Agile Velocity provides Agile Coaching/ Training (Scrum, Kanban, Lean), Agile Technical Practices Implementation and Team Augmentation Services.

Heard at the Houston ALN Conference

2012-01-23T15:34:00.000-06:00

"The role of an agile leader is to create the conditions for agility by taking action to change culture, structure, and goals"
"Fail at the small in order to succeed at the big"
“It is not the strongest of the species that survives, nor the most intelligent that survives. It is the one that is the most adaptable to change.” Darwin
"Leadership teams need to be focused on global optimization, not optimization of their own teams"
"Organizations need clarity on overall purpose, so that empowered self organizations can be powerfully successful"
"Shorten the decision paths, empowerment, alignment on purpose, shorten feedback loops"
"Never start without the purpose"
"Have metrics not to manage by, but to leverage to start conversations" Mike Young

You Can't Do Agile If You Haven't Seen Agile

2011-11-11T08:27:00.000-06:00

Mark J. Balbes, Ph.D.
11/10/2011

"You can't implement an agile program if you haven't seen it in a successful environment. It's just too different from traditional methods. If you try to do it without the help of someone who's lived it before, you are very likely to fail because you won't know the techniques to solve the unique types of problems that come up. Agile is not a panacea that will solve every problem. Sometimes it creates problems that you wouldn't have in a more traditional environment."

http://adtmag.com/articles/2011/11/10/agile-transitioning-must-see-agile.aspx

PURPOSE OF THE DAILY SCRUM MEETING

2011-01-06T12:25:00.001-06:00

The Daily Scrum Meeting is for the TEAM to self organize towards achieving their Sprint commitment

Objectives

Team Sync - The daily scrum is for the team to review progress toward their Sprint goal
Assess Risks - The team assesses any risks to their Sprint commitment
Adjust Plan - The team makes adjustments to their plan to meet the sprint commitment
Full Team - It is important for all team members to attend
Team Goal - Everyone needs to approach the Sprint as a team goal, not a set of individual goals
Team Ownership - Each team member should own and share responsibility of the full sprint backlog
Accountability – The team should hold each other accountable for achieving their daily commitments

Myths

Myth	Correct Action
The meeting is a status meeting for management (or the ScrumMaster)	The ScrumMaster purely serves as a facilitator on behalf of the team. Status to folks outside the team can be a secondary benefit, but it is not the primary purpose.
You only have to attend the daily scrum if you accomplished something towards the Sprint goal	As a team member, it is still important for you to engage in what the rest of the team is doing. It is also important for the rest of the team to understand why you are struggling to make progress.
It is the ScrumMaster’s responsibility to monitor and adjust the plan	It is up to the team to own the plan and make any needed changes
Everyone provides status to the ScrumMaster	The team should provide status to each other
No one pays attention to each other’s status (focusing on individual goals)	The team should focus on the team goal
Only the ScrumMaster identifies risks and mitigations	The whole team has responsibility for identifying risks and developing mitigation strategies

Tools

Sprint Backlog – Allows the team to have visibility into all of the tasks remaining to achieve their sprint commitment
Sprint Burndown Chart – Allows the team to quantify the amount of work remaining and if the team is on track

Key Metrics

How many days are left in the Sprint? --- This reinforces the urgency of a looming deadline
How many points have been signed off by the Product Owner? --- This reinforces that it only matters if we complete stories (not just getting to code complete)
How many hours are remaining compared to our target plan? --- This provides a view of how the team is progressing, most easily represented in a Sprint Burndown Chart.

Five Responsibilities of Team Members When Transitioning to Agile

2010-09-27T12:24:00.005-05:00

Transitioning processes and cultures simultaneously is very difficult. A Successful Agile transition requires team ownership and engagement in developing the best process to fit your unique culture and environment. Five areas where team members are integral to push the process forward and become successful are outlined below.

SEEK CONSTANT IMPROVEMENT

To achieve improvement, the team should define and align to the same goals. As a team, conduct an exercise to define the qualities of a successful team to focus them in the same direction and give them something to drive towards. Once the initial goals are met, set the bar higher and always strive to be better. Celebrate success internally and market your success externally. Share what is working and what the

team is learning with management and other teams.

GET CURIOUS

It is important a team push themselves to be better. In this industry, it is no longer acceptable to just be a tech expert; you also need to work more productively in a team environment. Take advantage of numerous sources of information by reading books and blogs and sharing interesting tidbits with your peers. Learn how others work since someone else has probably encountered similar problems.

CHALLENGE EVERYTHING

Just because someone else thinks it is the “right” way to do things, doesn’t mean it is. In early adoption, everyone is learning and no one is an expert. Always keep in mind there is no one right answer. Examine multiple points of view and try the approach the team thinks will succeed in your environment. It is natural to be skeptical, but try to be fair and open minded.

BE SOLUTION ORIENTED

It is imperative to maintain the right mental attitude. Change is stressful, but it is not constructive if you are not doing anything to fix it. Don’t just point out problems, but help devise solutions. Don’t blame outside the team, first determine how the team can solve the problem. If the struggle continues, then escalate.

EXPERIMENT

And the most important thing to keep in mind is in the beginning, you are not going to get it right. One advantage of short cycles is you can try something, gather some data, inspect the results and adapt from there. Try different options and tweak a little bit at a time.

David Hawks is an experienced Agile Coach at Agile Velocity

Why are our Sprints so Crazy?

2010-09-03T14:08:00.000-05:00

Do any of these issues sound familiar?

During Sprint Planning, it’s impossible for the team to break tasks into small enough chunks to be completed in a day
QA gets scrunched at the end of the Sprint
The team waits on design completion during the Sprint and cannot begin development tasks quick enough
Late in the process (sometimes after the Sprint ends), it’s determined that what was built wasn’t actually the right solution

Is there sufficient team prep work?
It’s a common misconception that within Scrum, the team should only work on the current Sprint’s stories and nothing more. However, this approach leads to inefficiency. In reality, every team should spend time preparing for the next Sprint in order to maximize productivity.

Requirements Clarity
To plan the story, the team needs to have a clear idea of what problem they are trying to solve and the boundaries on the scope. They need to work with the Product Owner, Stakeholders, Customers, and/or Users to better understand the focus of the upcoming stories. The team then works to refine the acceptance criteria to ensure it captures their understanding and assumptions of what is required by the story. This helps align expectations across all members of the team and with the folks requesting the story.
This can occur in full team discussions of the upcoming backlog with the Product Owner and Stakeholders, or with a couple members taking point to work through the details and then review with the team. Either way, all members of the team should possess a sufficient understanding of the business need.

Barely Sufficient Design
Once the clarity of the business intent is understood by the team, the focus turns to the solution. Some stories are small enough or don’t require substantial design making little impact if done during the Sprint, however others may require significant thought before unleashing the team for full planning or implementation. Typically, some activities (such as User Experience Design) occur before the beginning of the Sprint, so it’s available when tasking and the team isn’t blocked waiting on the UI Designer. This may also be required on a story that requires new Architecture decisions. If this activity is large enough, the team may need to break the story up so that it can be done incrementally. Perhaps do some prototyping work in one Sprint to prove out different technologies, followed by the final implementation story in a later Sprint. Or an incremental approach can be taken initially, avoiding the need to make a big up-front design decisions. (See Emergent Design).

Keep the goal in mind
The goal is to gain enough clarity of scope and solution to create a plan with sufficient accuracy relatively quickly, allowing the team to comfortably commit to a well detailed Sprint plan. The balance is to work ahead just enough without working too far ahead and without over engineering prior to Sprint start.

How does this work in Practice?
Typically, a team should allocate 10% of their capacity to work ahead. This could be 10% of every team member or a more significant percentage for some folks (e.g. UX Designer, Architect). Every member of the team should be engaged in some capacity so it’s clear what the team is being asked to do as Sprint Planning begins.

The team should set up a forum with the Product Owner to review stories and acceptance criteria to flesh out details and find gaps. This could be a regularly scheduled meeting one week before the next Sprint. The Product Owner should provide the initial set of Acceptance Criteria, while the team also takes ownership to hammer out the rest of the details. If the responsibility stays solely on the Product Owner, the team may become blocked and won’t benefit.

For each story, the team should also determine if any pre-sprint design work needs to be done. If large enough, the team may need to create tasks for the current Sprint to have visibility into what needs to be done and who is doing it.

How does this solve our problems?

Better understanding of requirements and solution will allow the team to have enough knowledge to task out the work sufficiently
Since expectations are aligned between developers and QA up front, QA no longer has to wait until they get the code to figure out what they need to test
Serial design processes are done prior to the Sprint so that work can begin immediately after the planning session
Requirement details are worked out with stakeholders prior to development beginning

Related Articles:
http://lithespeed.blogspot.com/2010/08/user-story-versus-requirement-and.html

Good Articles on mixing Maintenance with New Development

2010-07-07T13:34:00.000-05:00

Should you have separate product and maintenance teams?

How agile teams handle maintenance work

You might be on an Agile/Waterfall Project, if:

2010-07-07T10:23:00.000-05:00

I thought this business analyst times article was pretty spot on:
http://www.batimes.com/articles/you-might-be-on-an-agilewaterfall-project-if.html

Agile: If____, you may be on an agile project

If someone on your team actually offers you assistance, you may be on an agile project
If you've developed requirements and software at the same time, you may be on an agile project
If "waterfall" means taking a shower, you may be on an agile project
If you've had conversations with stakeholders who don't know what they want, you may be on an agile project
If fun means not having to refactor code, you may be on an agile project
If you measure progress in story points, you may be on an agile project
If you share office space with team members, you may be on an agile project
If you play poker just to estimate work, you may be on an agile project
If you correct your team mates code at the same time he writes it, you may be on an agile project
If the work pace of your team never changes and you only work on one thing at a time, you may be on an agile project
If you have not worked overtime in the last year, you may be on an agile project
If you actually implemented something in 30 days, you may be on an agile project
If you stand during meetings, you may be on an agile project
If you actually understand these jokes, and share them with all your friends, you definitely are on an agile project

Waterfall: If_________, you may be on a waterfall project

If your project sponsor dies prior to delivering the product, you may be on a waterfall project
If you are thinking of forging your sponsor's signature on the 27^th version of the business requirements document, you may be on a waterfall project
If you have worked on one project for the last ten years, you may be on a waterfall project
If you have a private office, you may be on a waterfall project
If you have a well written business requirements document that no one wants to read, you may be on a waterfall project
If testing is a phase in the way distant future, you may be on a waterfall project
If you have not met with your customer in the last week, you may be on a waterfall project
If 24 hours has passed and no one has asked you for a work status, you may be on a waterfall project
If you think a project will go according to your work plan, you may be on a waterfall project
If you have been working with the same people for the last twenty years, you may be on a waterfall project
If you think work attrition is caused by retirement, you may be on a waterfall project
If you have created documentation or know where it is, you may be on a waterfall project

If you hear the word agile and it reminds you that you are getting on in years, you may be on a waterfall project
If you actually understand these jokes, and share them with all your friends, you definitely are on a waterfall project

3 Different types of leadership required based on team maturity

2010-05-17T20:12:00.000-05:00

The 3 maturity stages of a software team and how scrum fails to identify them

While I agree with the main premise of this post that depending on the maturity of the team different leadership is required. Mainly that an immature team requires more direction and a more mature team requires less. But I think this author is confusing the Scrum focus on self-organizing teams with a self managing team. Scrum teams are not meant to be self managing. They do not set their own goals. The Product Owner defines what work needs to be done and management/ leadership still defines key goals like test automation, increase productivity, etc.

Leadership should always set direction and vision. More self organizing teams require less guidance on how to get there.

Real Developers Don't Need Unit Tests

2010-05-10T12:36:00.001-05:00

Check out this SlideShare Presentation:

Real Developers Don't Need Unit Tests

View more presentations from wakaleo.

Good Agile Leadership Posts

2010-04-20T10:38:00.000-05:00

I stumbled across these good posts on analytical-mind.com:

The 7 Dimensions of an Agile Project Team

What is Agile Leadership?
• Transfer certain powers to the team members themselves to let them determine how best to accomplish their tasks;
• Empower the project team through self-organization and commitment to results;
• Transfer decision-making to individuals who are closest to the activities;
• Demonstrate a greater openness to ideas and innovations emerging teams;
• Clearly define the desired vision and to adapt to the context of each team to ensure alignment with the overall objective of the project and to ensure cohesion between the team members;
• Provide the necessary support and resources to the project team so they successfully accomplish the expected results;
• Become a change agent within the organization by accepting and publicly endorsing the idea that the status quo is not acceptable and that the old methods are no longer adapted to the new reality;
• Systematically involve business people in the definition and execution of solutions;
• Adapt the style of management so as to use an inclusive and democratic approach.

Is your work environment Agile?
• Are all team members co-located?
• Does the physical environment support effortless communication?
• Are team members within 10 meters (30 feet) of a white board?
• Are team members allowed to stick post-it notes to the walls around them?
• Does the project team have access to natural light?
• Are team members allowed to decorate their work space?
• Do the project team members have access to free good-coffee?
• When necessary, do team members have access to private rooms to concentrate on their activities?

The 5 Dimensions of Leadership in an Agile Context

7 Principles of Lean Software Development

2010-04-19T17:53:00.000-05:00

I recommend reading Implementing Lean Software Development by Tom and Mary Poppendieck. They do a good job of breaking down the 7 Principles of Lean Software Development into some very easy to understand concepts. Here is a taste of what this book will open your mind to:

Principle 1: Eliminate Waste

• Waste is anything that interferes with giving customers what they really value at the time and place where it will provide the most value.

• Inventory is waste – In software that is partially done work

• Churn – Requirement Churn, Repeating test/fix cycles

• Many times caused by large inventories of partially done work

• When requirements are specified long before coding

• When testing occurs long after coding

• Delayed integration

• Overproduction - Extra Features

• Only about 20 percent of features in custom software are regularly used (66% are rarely used)

Principle 2: Build Quality In

• You don’t focus on putting defects into a tracking system; you avoid creating defects in the first place.

• Defect tracking systems are queues of partially done work

• TDD and Continuous Integration

• Write Less Code – Keep the Code Base Simple

• Expect to change existing code

• Refactor often

Principle 3: Create Knowledge

• Software is a knowledge creating process

• Validation of architecture comes as the code is being written

• An early design cannot fully anticipate the complexity encountered during implementation

• Expect the design to evolve

• Early release of minimum feature set to customers for evaluation and feedback

• Daily builds and rapid feedback from integration tests

• A modular architecture that supports the ability to easily add new features

• Encourage systematic learning throughout the development cycle

• Stop acting as if our predictions of the future are fact rather than forecast. Instead, we need to reduce our response time so we can respond correctly to events as they unfold

Principle 4: Defer Commitment

• Schedule irreversible decisions for the last responsible moment

• We should try to make most decisions reversible

• We should avoid making decisions that will lock in a critical design decision that will be difficult to change

• “In preparing for battles I have always found that plans are useless, but planning is indispensable” Dwight Eisenhower

Principle 5: Deliver Fast

• We need to figure out how to deliver software so fast that our customers don’t have time to change their minds

• Companies that compete on the basis of time often have a significant cost advantage

• Eliminated a huge amount of waste

• Low defect rates

• Repeatable and reliable speed is impossible without superb quality

• In fast-moving organizations, the work is structured so that the people doing the work know what to do without being told and are expected to solve problems and adapt to changes without permission

Principle 6: Respect People

• Entrepreneurial Leader

• A company that respects its people develops good leaders and makes sure that teams have the kind of leadership that fosters engaged, thinking people focused on creating a great product

• Expert Technical Workforce

• Appropriate technical expertise is nurtured

• Teams are staffed with needed expertise to accomplish their goals

• Responsibility-Based Planning and Control

• Teams are given general plans and reasonable goals and are trusted to self-organize to meet the goals

Principle 7: Optimize the Whole

• A lean organization optimizes the whole value stream

• Vicious Circle #1

• A customer wants some new features, “yesterday.”

• Developers hear: Get it done fast, at all costs!

• Result: Sloppy changes are made to the code base.

• Result: Complexity of the code base increase

• Result: Number of defects in the code base increases

• Result: There is an exponential increase in time to add features

• Vicious Circle #2

• Testing is overloaded with work

• Result: Testing occurs long after coding

• Result: Developers don’t get immediate feedback

• Result: Developers create more defects

• Result: Testing has more work. Systems have more defects

• Result: Feedback to developers is delayed further. Repeat cycle.

If you are looking for a basic introduction to Lean Concepts I would recommend reading the Goal.

New Mike Cohn Post - Agile Teamwork: 3 Ways to Minimize Handoffs

2010-04-14T15:42:00.001-05:00

Agile Teamwork: 3 Ways to Minimize Handoffs

· Stop Writing and Start Talking - “When documents are mostly to enable handoffs, they are evil. When they capture a record of a conversation that is best not forgotten, they are valuable.”

· Transfer Small Tasks Frequently

· Create a Manageable Mix

4 Reasons to have Cross Functional Teams

2010-03-31T12:57:00.000-05:00

Enables ability to create shippable product inside the sprint - By including everyone required to go from idea to implementation the business can benefit from having deployable product every couple weeks and can capitalize on the investment earlier.
Improves Collaboration - By having everyone involved in the same meetings and same discussion regardless if it is about Design or QA strategy it encourages folks to work together. You can get all perspectives creating more productive discussion.
More efficient - Limits dependencies and handoffs. Reduces duplicate communication and need to document for another team. This allows the team to focus on delivering business value.
Alignment of Goals - Keeps the team focused on common goals as opposed to one team with architecture goals and another team with Quality goals.

Top 5 ScrumMaster Pitfalls

2010-03-15T14:38:00.000-05:00

Here are my top 5 observed ScrumMaster pitfalls:

Doing the Problem Solving - Instead of empowering the team and coaching them to own the problems, the ScrumMaster jumps in and solves the problems for the team.
Losing sight of the Big Picture - Focusing the team too much on the current sprint and not providing enough attention to the next Sprint and full release.
Not radiating information - By leaving data hidden in tools or not talking about the burndown daily. Make metrics visible and make sure the team is talking about their sprint and release progress. Don't just stop at the burndowns, display any data that will help the team adjust and improve.
Just tracking impediments - A ScrumMaster shouldn't be the only one owning the removal of an impediment but they need to ensure they are getting closed quickly.
Being a pig - Often when ScrumMasters become pigs doing sprint tasks they get in the critical path and lose focus on the big picture and the team progress.

4 Advantages of Physical Task Boards

2010-03-07T14:22:00.000-06:00

For new teams I try and encourage them to use a physical task board over tracking tasks in a tool. This can be problematic when all team members are not in the same location, but it has some huge advantages for co-located teams.

Structure of our Task Board:

5 Columns: Planned, In Progress, Verify, Hours Remaining, Complete
Each Committed story for the iteration is given a swimlane/ row
All Development tasks are on white cards
All Testing tasks are on green cards
All defects are on hot pink cards
Orange sticker dots were used for tasks that are blocked
Story cards are 4x6, task cards are 3x5
We have used whiteboards with tape or cork board with push pins
Daily Standups are done in front of the board, we encourage team members to point at the card during their 3 questions, move cards, burndown hours. Each team member should be signing up for their daily commitment and putting those cards in progress.
Hours burndown is updated for each story at end of standup
Burndown chart and any other metrics are placed on and around the board - radiate information
Should be visible to all team members (i.e. that way when a QA person sees a developer move a task they know to ask if it is ready for testing)

Advantages of Task Boards:

Promotes team interaction and discussion - Throughout the day you will see teammates, stakeholders and members of other teams stop by the board for discussion. This increases greatly if the board is located near the team and highly visible
Visibility - Anyone walking buy can make a quick second assessment on where the team is in the iteration. No cards left for a row? That story is complete. No white cards left, just green cards? Only testing remains. Lots of pink cards? Lots of defects.
Good for new teams to visualize Scrum - By having this tangible thing in front of them that they can touch, makes it easier for new Scrum teams to understand the process
Support full team commitment - Now the whole team sees all of the tasks daily and keeps them from just focusing on "their" tasks. When using task tracking tools it is too easy to just create a view of "my tasks" and then tune out the rest.

Agile Estimation Workshop

2010-02-28T13:58:00.000-06:00

Here are the Agile Estimation Workshop slides that I used for the for the Agile Austin Workshop this weekend.

http://docs.google.com/present/view?id=dgswtwn6_54cw3dpwrt

For further knowledge I would recommend Mike Cohn's book on the subject:

5 Reasons Why Estimating in Story Points is a Superior Method

2010-02-21T14:56:00.001-06:00

I get a little resistance from teams to start using Story Points for estimating, but it really is a superior way to estimate over hour based estimates.

Story Points should be used to estimate User Stories and quickly provide estimates to the Product Owner so that they can prioritize the product backlog. I recommend using the Planning Poker technique to get everyone on the team involved and timebox the estimating process.

What are Story Points?

Story Points are a relative measure of complexity, i.e. How big a feature is compared to other features. This type of estimating removes the notion of time from the estimate as team productivity is measured separately as Velocity.

Advantages:

Quicker to Estimate

Keeps Things Relative - Two team members can agree quicker that one feature is twice as complex as another compared to agreeing on how long it will take to implement. A senior developer may argue that it takes 2 days while it will take 4 days for a junior developer.
Stay out of the Weeds - If the team has to think about every little thing to build a bottoms up hours estimate then they will tend to try and understand every requirement detail and think through the design to much. When estimating in points you only have to think about comparative complexity, as opposed to trying to think about everything required to implement the feature.

Do Not Get Stale - As team productivity changes there is no need to re-estimate. Velocity will change but the comparative complexity will still be valid.
Better Metrics - Since scope is isolated from productivity I can now report on how the scope is changing. If I had my estimate in hours it is difficult to determine if the change was from a scope or productivity change. For a release I like to report two main things to my stakeholders: scope (total points recorded at each sprint) and work completed/ velocity. This gives me clear visibility to both scope and velocity compared to the plan.
Inaccurate Estimates get Resolved - If up front the team made overly optimistic or pessimistic estimates we will gain quick visibility to this as the team records Velocity in the first couple iterations.We will then be able to adjust the plan accordingly without having to re-estimate.

Articles of Reference:
The Case for Story Points - Peteon Rails
How Do Story Points Relate to Hours? - Mike Cohn
Agile Estimating Presentation - Mike Cohn

Suceeding with Agile

2010-02-21T14:24:00.000-06:00

I am reading Mike Cohn's new Book. So far it has the potential to be one of the top books that I would refer to folks.

Kanban development oversimplified: a simple explanation of how Kanban adds to the ever-growing Agile toolkit

2010-02-18T21:49:00.000-06:00

I am still trying to figure out where Kanban fits in this Agile world. Some part of me thinks it is for people that can't be disciplined enough to do Scrum well, but I can see some use for some support and sustaining development teams whose priorities may change very often due to business needs. I stumbled on this article as a decent primer to Kanban.

Kanban development oversimplified: a simple explanation of how
Kanban adds to the ever-growing Agile toolkit

Agile Estimating Workshop

2010-02-17T09:27:00.001-06:00

I am facilitating an Agile Estimating Workshop on Sat. Feb 27th. If you are interested sign up here:
http://agileestimating.eventbrite.com/