We're an Agile Family!

Agile family
A colleague sent me this TED talk, Agile Programming for your Family. I know of companies that have used agile methodologies outside of technology including marketing, construction, and operations. But to be an agile family with a scrum board, and family retrospectives?

It actually makes sense if you can avoid becoming a "tiger" agile family and don't catch any backlash from your teenage daughter for bringing a geeky process from the office into the home.

I like the agile family manifesto suggested by Bruce
  • Adapt all the time - This is fully aligned with agile principles that support prioritization with every sprint. The bottom line is that kids and family life are highly volatile - kids get sick, trouble in school, birthday parties, and all kinds of events and behavioral changes that are out of parental control. Adapt = reassess and prioritize.
  • Empower your children - Again, this is in line with agile principles of self-organization, though it might feel counter-intuitive with kids especially when they are young. Bruce suggests starting early when they are young, which makes sense given today's environment and the choices kids have to make on their own.
  • Tell Your Story - This is equivalent to setting your vision. Tell your team who you are, who you want to be, and what are your core values.

But my favorite line, and why Bruce says this works is "You can't underestimate the power of making a checkmark." Done.

continue reading "We're an Agile Family!"

How to Conduct an Agile Story Sizing Meeting

2013_02_05_0669
Agile Construction Team
As I discussed in my last post (Three Agile Insights working with Offshore Teams), I spent the last several days visiting offshore development teams and had the occasion of observing one team performing an Agile Sizing meeting. Sizing is a critical task performed by agile teams and the process attempts to put an estimate on the cost, complexity and risk of a Story prioritized in the backlog. The sizing serves a number of purposes
  • Developing the metric is a mechanism for individuals to share their understanding of the requirement, ask questions, and to discuss any complexities with the implementation.
  • It provides feedback to the product owner, architects, and stakeholders on the overall complexity of the Story. If a story is sized high, it may cause one to challenge the priority of the story or provide grounds to question the team on approach.

 

Conducting a Sizing Meeting

The journey is more important than the result. This meeting serves a greater purpose than just getting a number on a Story - it's a mechanism for teams to collaborate and challenge each other. Teams that overly rely on planning poker and other mechanical tools to vote on Story Sizes may miss out on an important team dynamic. So while observing one team I truly appreciated how it managed this meeting.
  • The backlog was displayed on a large monitor for all teams to see.
  • Remote team members participated including QA.
  • The Lead (tech lead on our teams, ScrumMaster may be appropriate for others) read the story.
  • The Lead called out each person on the team to relay their thinking of the story and to announce and justify the size.
  • The Lead decided on the final size - often taking the maximum set by team members. Stories that could not be sized or where there was too much variance by individuals were not sized.
  • The story was updated with the agreed on size in the backlog.
  • The meeting was conducted efficiently going from one story to the next until all stories ready for sizing were reviewed.
What I appreciated most was the dialog that led to either a shared understanding or questions that needed clarification. The meeting had a fast rhythm to it, driven by the Lead, insuring that each team member was called upon to speak. The rhythm forced individuals to be specific and concise on declaring their story size and rationale.

Valuable, efficient, and productive.

Note that in the Agile practices I sponsor, Sizing is a distinct and separate process than Estimation as you can see from my earlier post on How and Why to Estimate in Agile. I'll connect these two processes in my next post.

continue reading "How to Conduct an Agile Story Sizing Meeting"

Three Agile Insights Working With Offshore Teams

Every year, I make the trip to India to visit teams that work as developers, testers, and support of our applications. And every year, after meeting the teams, talking to management, making presentations, and seeing future possibilities, I always come away with some new insights. Last year, it inspired me to right the post Top Itineraries for the CIO's Offshore Visit.

So today, halfway through my 2013 trip, let me share you some insights

1) Agile teams need to govern their process - What are your rules, when do you bend them, and when do you call out an issue? Are developers going to accept poorly defined stories and permit changes in scope during a sprint? Will testers speak up when stories are more complex than the development exercise and should be sized accordingly? Are blocks formally documented and resolved quickly, or do they linger? Agile teams achieve higher levels of productivity, quality, and job satisfaction when they talk openly about places where improvements are needed.

2) On the same page - I've written before on how important it is for teams to have a shared understanding of their goals and requirements. One really important step is to insure agile stories have pass/fail acceptance criteria. "The email form should make it easy for users to enter multiple email addresses" could easily be rewritten as "The email form should allow entering up to ten email addresses" which clearly provides a business rule and some guidance on the user interface.

3) Self Organizing = Data Driven teams - Once teams have settled on their agile practice, it is important to discuss and select some metrics to track and use to drive improvements. Are your performance metrics stable with every release? What percentage of your test cases are automated? How many defects were created? When discussing potential issues, teams perform better when metrics are developed and used to drive improvements.




continue reading "Three Agile Insights Working With Offshore Teams"
Share

About Isaac Sacolick

Isaac Sacolick is President of StarCIO, a technology leadership company that guides organizations on building digital transformation core competencies. He is the author of Digital Trailblazer and the Amazon bestseller Driving Digital and speaks about agile planning, devops, data science, product management, and other digital transformation best practices. Sacolick is a recognized top social CIO, a digital transformation influencer, and has over 900 articles published at InfoWorld, CIO.com, his blog Social, Agile, and Transformation, and other sites. You can find him sharing new insights @NYIke on Twitter, his Driving Digital Standup YouTube channel, or during the Coffee with Digital Trailblazers.