Heard at the Houston ALN Conference

"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

• 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

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.

Related Articles:

http://agilesoftwaredevelopment.com/blog/peterstev/scrummaster-murphy-ten-problems-daily-scrum


http://agilesoftwaredevelopment.com/blog/artem/7-tips-daily-scrum


http://martinfowler.com/articles/itsNotJustStandingUp.html

Five Responsibilities of Team Members When Transitioning to Agile

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?

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

Should you have separate product and maintenance teams?

How agile teams handle maintenance work

 

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

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