Friday, July 18, 2014

Leading Agile Teams


Over the past week I interviewed four of the agile team leads at my organization. The responsibilities of these folks range from agile implementation to process improvements to providing direct leadership to the product development teams. Along with my list of 11 questions to guide the conversation, I added a 12th question for each one of them that was a wrap up based on how the interview had gone and what was a distinctive point that they had touched upon. It was a great insight into the workings of other agile team leads within my organization. There will be another post detailing the findings of these interviews, but here is the teaser. LPE is the designation for an agile lead at my organization.

Is Leading Your Team More People-Management or Project Management?

"Team management is what an LPE does".  According to Mike who has been in his current role for about three and a half years, it is a bit of both. He feels that he mentors, advises and helps individuals define and achieve goals and at the same time ensures feature delivery, resource allocation and works with product managers to maintain scope and set project expectations.

It is an undervalued aspect of a scrum master or any other type of agile lead that gets lost in all the process that the lead has to be a good people manager in order to be successful. Beyond all the numbers and the process improvements, an agile lead has to have the right people skills to bring teams together and lead them in a united direction. 

How Do You Cope With Major Crises Your Team Faces?

"Once you have experienced crises, you develop immunity." This from an LPE whose team is often faced with critical client issues. "There are much fewer butterflies after 6 or 7 months". He also mentions that having good support from management for the team helps quite a bit and gives the team and him confidence in dealing with critical issues.

Having been on such a team in the past, I would echo the comments made above. In any form f leadership or crisis management situation, experience is the best preparation. Once you have handled tough situations or critical, time-sensitive issues, the next time just becomes easier. The important piece becomes how the leader of the team lets this affect the team. Does the leader make the required changes to avert such crisis and make the handling of the crisis straightforward to avoid stress on the team?

How Do You Receive Feedback and Suggestions From The Team?

Mariana, who has been LPE for her team for about 3 and a half years uses "Retrospectives and one on ones" as her primary mechanisms for collecting feedback from the team.  She does note that a lot of improvement suggestions and process feedback is "free flowing" and comes through casual conversations in the team room.

I asked Mariana this questions as she indicated numerous changes that had been made by her and the team to the way they work and it highlights the collaborative nature of effective teams. Teams that improve continuously usually do so because the team members themselves are interested in getting better. As opposed to anyone outside, the team knows its working conditions the best. On the other hand though, getting a fresh perspective from someone outside the team can help see issues that are hidden in plain sight.

What Would Be Your Advice To New Leaders Of Large Teams?

"Use the right resources for the right tasks" says Yvette who leads a team of 28 developers. "Use your resources to the best. If they do not perform in one area, move them to another. Find the right fit for your team members."

Every team has its challenges and opportunities. Yvette's team deals with a wide variety of problems and this gives her the freedom to try to "find the right fit" for her teammates. This is a great example of how the agile lead uses the opportunities afforded by the team's nature to make the members of the team and in turn the team itself, more effective.

It has been a great experience interviewing my peers and there is a lot more from these interviews that should be share. More of that in upcoming posts. Thanks again to all that participated so far and other that will in the future.

Monday, June 16, 2014

Agile Development Conference West Roundup

I spent the last week at the Agile Development Conference West and got to meet a great and varied set of speakers and attendees

James Whittaker, Distinguished Engineer at Microsoft, presented the future of web based data. Whittaker is not happy with the present, that requires users to log into apps or open up a browser to get to information. Whittaker gives an amusing example of the RunPee app that he saw his date using during a movie(it prompts you about the least interesting parts of the movie, so that you can visit the bathroom in theaters). He points out that this is an app that many folks might find useful, but it is buried so deep in the iTunes store that must potential consumers will never see it. He believes that "A new era of domesticated information and functionality is dawning" and that everyday applications will start bringing the data to you, rather than you going to multiple applications. 
Whitakker presented an example of this in the form of a holiday booking done through the Outlook calendar. He first blocked off the dates on his calender for when he was going on vacation, which made the calendar prompt him with the option to buy travel tickets. It showed the flight dates and times on the calendar, showing exactly the times the flight spans. Next after the booking of the tickets, the calendar suggested activities(for example, if you are visiting London - Visit Buckingham Palace, Hyde Park, Eat at recommended restaurants) and the user could then drag these directly onto your calendar and the application can even make the reservations for you. This was a great example of getting rid of the "hunting and gathering" done via browsers and apps and the domestication of data and information. 
The next part was just incredible, Whittaker showed screenshot of a plugin being developed that through the context menu, can be invoked to search for code samples that fit the problem being solved from the MSDN community posts. These can be imported and they get auto re-adjusted to use the variables being used in your code. This is an incredible tool for developers faced with problems they are sure someone has solved before. While this talk did not have much to do with Agile development, it did though have a glimpse of the direction applications are headed for many folks who would be helping develop them.

The title of the talk promises much and delivers more. Joe Justice is a consultant with Scrum Inc. and the founder of Wikispeed. Joe made one of the most impactful presentations of the conference. He introduced us to the revolutionary Wikispeed which builds modular cars using agile methodologies. They use agile boards(even for legal, hr and accounting) at Wikispeed to build cars. They use "object-oriented" car parts which are hot-swappable and can be switched out for similar parts as they have the same interface as every other similar part. This is revolutionary in the field of car manufacturing as it focuses on innovation and incremental delivery as opposed to mass production. Whats more, they are not for profit. Wikispeed has the ability to create new cars every week as opposed to the months to years it takes for a traditional car company to create and launch a new model. The cars they have built give over 100 miles per gallon. 
 Justice has taken these concepts to other hardware and manufacturing companies. He consulted with a radio amplifier manufacturing company in New Zealand. They co-located all disciplines needed to make  new product and started working with a scrum board and even using tdd(using card board pieces to run tests for size and fit before fabricating the actual metal parts). They went from creating a new product in 2-3 years to 2-3 weeks. John Deere, Boeing, Lockheed Martin and Raytheon have also adopted these methods with great results.
The most incredible story was that of Eduscrum. This is a group introducing scrum to classrooms. Justice gives the example of a science class where the teacher is just observing, while the students are learning by moving their tasks across their individual scrum boards. When they are done with a task, they ask the teacher over to review the task so that it can be closed. Justice's observation was that the students were a lot more involved and the teachers were a lot more relaxed.
This was my favourite talk of the conference. Having used personal kanban, I had an idea of uses of agile concepts outside of software, but using this for hardware development and education, to such great effect was incredible to see.

Sanjiv Augustine presented his talk on innovation and the right way to do it using Lean Startup concepts. Augustine gave examples of Kodak and Polaroid, which were big players in the 80s and the early 90s but quickly fizzled out because they did not innovate. Nest, Airbnb and SouthWest Airlines were given as examples of those that used lean concepts to be disruptive in their markets. The moral of the story was to be innovative while you are successful and to plant the olive tree. The gist of the talk was to make sure you have customers before building a product and to get customer feedback early and often.
Augustine showed a video of Nordstorm innovation labs where they performed flash testing directly with the customers to illicit requirements. The team spent a day at a shop selling sunglasses creating an app to help customers compare and buy sunglasses. They worked off of the direct feedback they got from the customers and had a successful app by the end of the day. This type of interaction can help figure out the MVP(Minimal Viable Product) and pivot the direction of the product early. It also helps the team empathize with the customer.
In all the talk was interesting, especially the Nordstorm portion of the talk. Watching a team work at such close quarters with the users was very exciting to see. I would love to try this out with one of my teams in the near future. Showing the video to my team got the same reaction, every one is excited to try this.

With 25 years of industry experience and an arsenal of research data to back him up, Mah presented numbers, trends and graphs that showed the impact Agile and clean code practices have had around the world. Some numerical highlights from the talk - 
  • A factor of 4 reduction in bugs can be achieve by using XP, pairing and co-located teams.
  • Geographically distributed teams can have up to 3 times the number of bugs dues to inefficient communication.
  • Schedules can be made shorter by up to 30% using agile.
  • Companies adopting Agile hit their stride around the 2 year mark.

Mah also compared the state of agile in Columbus and Munich and found the following -
  • Columbus teams were larger than Munich for similar size projects.
  • Projects in Munich had lower cost.
  • Projects in Columbus moved faster.
  • Columbus projects had fewer defects.
As a numbers guy, I found this to be more interesting than most of the audience did. It was good to be able to pick Mah's brain during lunch following the talk. He seems to focus a lot more on trend-lines than data-points, which is important for all to keep in mind.

Fadi Stephan from Excella Consulting led a session on what metrics to track for your agile team. It was a very different perspective on velocity, which is the almost universal metric tracked for agile teams. Stephan is against publishing velocity and using it purely as a planning tool. In fact Stephan reiterated the fact that teams should stop measuring velocity after it stabilizes. His advice is to keep the velocity number within the team and show only value delivered in showcases. Metrics should be used to encourage the right behaviours, not just for measuring outputs. Stephan suggests looking at the 12 agile principles and figuring out how to measure them. For example, producing valuable software can be measured by doing customer surveys, cumulative flow diagrams can be used to measure collaboration on the team. A metric should lead to conversation and eventually change, measuring things that do not invoke change is useless.

Personal Reflection
The conference was a mix of some great talks and some average ones, as one would expect. Chris Sims and Peter Saddington also made some great presentations about Business value and mentoring respectively. Joe Justice and Fadi Stephan were my favourite of the conference. Justice's examples of application of agile beyond software were very eyeopening. At the same time, Stephan refocused the use of metrics in the agile sphere from the routine velocity measurement.

Special Interest
Here is the Nordstorm Innovations Lab video that I had mentioned earlier in the post. Let me know what you think.


Friday, March 14, 2014

Agile is dead...but roundup lives.

It has been a bit of a break for the Roundup, but its back. There has been a lot of action in the blogosphere and a lot of it has prompted personal reflection and change. Change based on what we have learned, that is how we know we are agile, right? Hoping to add a more personal reflection piece to this blog going forward. We will still review the best and brightest agile-related content out there, just with a little more of personal insights thrown in. Her we go...

Agile Is Dead(Long Live Agility)
http://pragdave.me/blog/2014/03/04/time-to-kill-agile/
Summary -
Dave Thomas, one of the originals, who drafted the agile manifesto, expresses his dissatisfaction with the direction that Agile has taken over the past decade or so. Dave puts in words what we practitioners feel every day - Agile "rules" are dumb if followed blindly and dogmatically. Agility is the essence of the agile principles not the mindless following of "best practices". Use Agile as an adjective not a label. This is not about implementing processes that profess to be the embodiment of Agile but to be truly embedded in the concept of Agility. To do what suits best to move closer to your goals and use the lessons and the understanding gathered to correct your path toward your goal. Do not use practices as a benchmark for agile, but use true agility as your guide. If you have any doubts about whether you are "Doing Agile Right" or not, read this. This is the most important blog post that has shown up of late in the agile world in my opinion.
Favourite Snippet -
That’s just plain wrong. “Do Agile Right” and “Agile for Dummies” are just two of the innumerable attacks on the English language featuring the word. They are meaningless. Agile is not a noun, it’s an adjective, and it must qualify something else. “Do Agile Right” is like saying “Do Orange Right.”

http://jeffarchibald.ca/60-hour-work-week-badge-honour/
Summary -
Jeff Archibald, founder of PaperLeaf, writes about Overworking. This one also hits home. As a developer, I have done this multiple times in the past. Even as a Scrum Master, Agile Coach or Team Lead, I have done this many many times and know what it means. Archibald admits to this as well and reiterates how this is a sign of a broken system. He also introduced me to the term - humblebrag, which is a very apt term for the phenomena. Archibald recognizes this as a sign of you being a bottleneck or not delegating enough and "trying to be too many things". Archibald does allow for this on occasion, but recognizes that if this is a usual thing, something is broken in the system.
Favourite Snippet -
We need to stop being proud of overworking ourselves. It’s unhealthy, it stunts the growth of the business, and it’s unsustainable. Instead, we should be proud of creating or working in an environment that is efficient, organized, and diligent enough to allow people to work regular hours on meaningful work.

Mob Programming
https://www.madetech.co.uk/news/mob-programming-at-made
Summary - 
Scott Manson(self professed "Power ballad aficionado"), writes in his February post about Mob Programming. This is basically code review on steroids. Gather every developer from your team together, select a piece of code to review/refactor and have the entire team provide input on the refactoring. One monitor, one keyboard, one machine. On the face, the practice looks like the edge of chaos, Manson finds the first foray for his team enjoyable. It seems that the more experienced members of the team dominated proceedings. Manson's proposed solution to this is having all team members spend equal time on the keyboard taking the lead in expressing their ideas. Having lived in the world of Pair programming for the last year or so, this seems to be a great exercise for spreading knowledge and best practices within the team.
Favourite Snippet -
The main aim of these sessions is to learn collaboratively, so we want to encourage everybody to get involved.


Personal Reflection
Thomas's post is a breath of fresh air. It reconfirms for me some concepts that I have had in my head that have been battling with some "proven" agile practices. The team should be free to exhibit agility the way they feel is best. The team should also guard against using this as a license to abandon agility. Abandoning agile is not the same as abandoning agility. Archibald's post also hits home. It is not just the humblebrag, but actually the personal satisfaction one derives from doing the best(or most) for the team. It is not healthy for the individual, the team or the system as a whole for team members to be continually working 60 hr weeks.

Special Interest
To commemorate pi day here are 17 equations that change the world by Ian Stewart -
tumblr_n2c8noLd1q1qzy0ygo1_1280.jpg (599×784)

Sunday, January 5, 2014

Musings from the end of last year

Happy new year folks! Hope every one had a great new year eve and has their resolutions/objectives in order for 2014. Some of our friends int he blogosphere did not take the holiday season off and continued to produce posts, some of which are rounded up here for you. There is also a post on personal Kanban to help you get those pesky resolutions taken care of.

Limit Your Holiday WIP With Personal Kanban
Summary -
Derek Huether, at The Critical Path, talks about applying Kanban to your personal life. He talks about it from the holidays perspective, when to-do lists get out of control, and also from a generic perspective of everyday tasks. Huether demonstrates how he effectively manages his tasks using color coded cards and columns with WIP limits. He also uses a focus column to make sure he knows which task has priority so that " Everything else can wait. I need to get this done!". His post made me try out Kanbana and in two days of trying it, I can already see myself getting things done.
Favourite Snippet -
"I’m a strange combination of a little OCD, a little ADHD, a lot of grit, and a lot of drive.  I need a focus column.  If I walk away from my desk, read an email, or get a cup of coffee, I can pretty much guaranteed to forget what I was working on."

Summary -
Intuit's "The Fast Track" blog has a couple of "geek out" posts by Carol Pinchefsky that bring project management and sci-fi geeks together. The first of these is lessons from sci-fi for project management. It covers movies and TV shows from Star Trek to Robocop to Batman Begins. here is the summary of lessons learnt, you will have to read the blog to figure out how Pinchefsky gets there - 

  • Star Trek - Challenge your assumptions about your project and think outside the box.
  • Robocop - Better projects can be born out of the ashes of failed ones.
  • Buffy The Vampire Slayer - Motivated employees become star performers.
  • Batman Begins - Don't be afraid to move the best and brightest off the project if they are not team players
  • Ghostbusters - Speculative ventures can be very fruitful, but dont expect all such ventures to succeed.

Favourite Snippet -

"Business is like a first wife: There’s always a newer, improved version in the future."

Summary -
Carol Pinchefsky follows up her post about positives from Sci-fi with horror stories that are lessons for what not to do as a Project/Product manager. This time around we have classics like 2001 : A Space Odyssey, Aliens and Star Wars included in the list of inspirations. So read this if you don't want to be like Darth Vader or HAL. Here are the lessons -

  • 2001 : A Space Odyssey - Don't give your team conflicting requirements.
  • Captain America - Poor documentation and knowledge concentrated with individuals is toxic.
  • Aliens - Listen to the concerns of "problem" employees and check in often.
  • Star Wars - If you use terror to lead, your team members wont give their best.
  • Prometheus - Build your team with the right type of players.

Favourite Snippet -

"Guess whose job it is to facilitate the communication and make sure the requirements are aligned? Yup, that’s why they pay you."

Summary -
Peter Brodzinski on his Software Project Management blog, ended the year talking about value and what value truly means. He asks the very relevant question of how do we define value? He argues that value for the client is not the only answer, there has to be some reciprocity. Brodzinski points out that, the software vendor, the client and the users should all be a part of the value equation and this equation should be balanced. The decision of which metrics or value points to put emphasis on is very contextual and driven by many factors, and of course, these factors force us to make choices on what we value.
Favourite Snippet -
"Only if you are able to tell which factors are important in a given context you can come up with reasonable measures of value."

Wednesday, December 18, 2013

An Agile Holiday

Merry Christmas(Or Happy Holidays, depending on your preference). There is a little Christmas treat for you in today's post. A look at Mike Cohn's Christmas list for Scrum Masters and our first look at one of my favorite agile/life blogs - The Hacker Chick Blog. Also, Wall-Skills, a peppy single page pamphlet-style image collection. Have a jolly time reading my friends.

Playing The Scrum Master Role
http://www.scrumalliance.org/community/articles/2013/december/playing-the-scrummaster-role
Summary -
Francesco Attanasio from Ericcson write about the Scrum Master role over at scrum alliance. He lays out the key expectations of the role and how it is a full time job on the team. There is an interesting picture that outlines typical scrummaster tasks for a two week sprint. It feels a little forced to come up with 80+ hrs of work for the scrummaster. I dont agree with the resulting distribution of hours as a scrum master(or the two other incarnations of the same role under other agile methodologies that I have played) does a lot more and does not usually spend his/her time on the same set of tasks every sprint. Francesco stresses the importance of the scrum master as a coach and why it is important for this not to be a rotating responsibility.
Favorite Snippet - 
 "I know that if we, as a family, need to eat good food, my wife, the best cook, is the one for that role. Yes, it is possible to rotate the job of ScrumMaster, but, like Mike Cohn, I would recommend doing it only rarely and temporarily."

Top Ten Gifts For The ScrumMaster In Your Life
http://www.mountaingoatsoftware.com/blog/top-ten-gifts-for-the-scrummaster-in-your-life
Summary -
Mike Cohn kicks off the Holiday season with a funny, yet interesting(and slightly self promotional) post about gifts for ScrumMasters. These include a Bullhorn, an Atomic Clock and my favorite - "We'll try anything for two sprints" certificate. It is a funny post but the three out of four links leading to Cohn's book or the MountainGoat website do act as dampeners.
Favorite Snippet -
" I guarantee your ScrumMaster would love a handmade note from the whole team saying, "We'll try whatever you want for two sprints." What a wonderful way to demonstrate your commitment."

Do One Thing Every Day That Scares You
http://www.hackerchick.com/2013/11/do-one-thing-every-day-that-scares-you.html
Summary - 
The Hacker Chick Blog is one of the most enjoyable reads of Agile-related blogs every time there is a post. Abby Fichtner, who also works with the Havard Innovation Lab, puts out some very fun and interesting material. Her latest post is about her experience at the 99U conference. Fichtner talks about how success affects creativity and even more about how fear holds you back. It is a very relevant topic for any of us who are adopting Agile or new agile practices. On the face of it things might look absurd, but then there is that famous Einstein quote.
Favorite Snippet -
"And so each day we decide. Do we do that which calls to us or that which the world seems to “want” from us? Albert Einstein once said that “if at first the idea is not absurd, then there is no hope for it.” But first, we must have the courage to trust in ourselves."

Agile Laws
http://wall-skills.com/2013/agile-laws/
Summary - 
Wall-Skills specializes in one page leaflet style pages that highlight details on specific topics. They have an Agile & Lean section that contains some pretty cool leaflets. The latest one summarizes the laws most quoted in and most pertinent to agile development. Whether you agree with broad agile premises or not, you would mast likely agree with these. They form the basis of a lot of the recommended practices and for most developers give more context to why a certain practice might work, or what was the reasoning behind the recommendation.

Sunday, December 8, 2013

Agile Requirements - Writing, Grooming, Refining

This is where it starts, without well thought out and laid out requirements the story/feature/project can be a vague idea open to diversions, misinterpretations, unending iterations within the team and international conflicts. Let us explore some of the opinions and commentaries made recently on the topic of Agile Requirements. These individual posts explore practices that can range from a single acceptance criteria in a story to overall backlog refinement.

Summary -
In his post "Why Write Requirements" Scott Sehlhorst takes a step back from the "How" of writing requirements to the "Why". Sehlhorst lays out 6 major reasons for writing requirements and how they fit into the Agile sensibilities. His six biggies are as follows -

  • Understanding Your Market
  • Sequencing Delivery
  • Collaborating With Delivery
  • Managing Expectations
  • Improving Efficiency
  • Remembering Intent
Favorite Snippet -
"Teams that ignore opportunities to get smarter about changing needs will also, by definition, build stuff that isn’t needed."

Summary -
Griffiths talks about the starting from scratch projects where overall direction is not yet defined. He shows how the uncertainty allows for the ability to prioritize the highest business value items. Griffiths shows the positives and negatives of both traditional and agile requirements. It is a pretty unbiased look which recommends horses for courses, while giving a quick tour of the advantages of both approaches. He accepts that this is a "bipolar view of the world" while presenting the two ends of the spectrum.
Favorite Snippet -
" If you know you want a vacation at the Hotel Del Coronado in San Diego and that ticks all your boxes then you can lock down the requirements early, book it and be done with it. If you are not sure if the twins will be joining you for a vacation and are looking for the best value 4 star hotel; you will want to keep your options open longer and have some flexibility to best satisfy your purchasing needs." 

Summary -
In his November 5th post at The Critical Path blog, Derek Heuther defines a new ceremony for agile teams called "Backlog Refinement". He recommends an activity in which representatives from the management team, product owners and agile team members get together to look at work that is scheduled for 1 or 2 iterations ahead. The general idea is to start from the bigger picture to prioritize the backlog and at the same time make sure that the stories have the correct Acceptance Criteria (aka Conditions of Satisfaction) and follow the invest model.
Favorite Snippet -
"Do not wait too late to add details, because the delay will slow the team down. Do not refine your stories too far in advance, because the details might get stale."




Summary -
Scott Amblers and associates' Agile Modeling is a great site for agile resources, especially for design and analysis. This essay describes 16 guiding principles of agile requirements. While it is a bit of information overload, it is a great post to revisit periodically. The best practices run the gambit from "Adopt Stakeholder Terminology" to "Take A Breadth First Approach". 
Favorite Snippet -
"...project stakeholders should be involved with modeling and documenting their requirements, not only do they provide information but they actively do the work as well."

Grooming The Backlog, Combing The Desert
http://jeffryhesse.com/blog/agile-mondays-grooming-the-backlog-and-combing-the-desert/
Summary -
Jeffry Hesse in his Agile Mondays series recently talked about backlog grooming. He attempts to, as Heuther does in his post, firm up the "sort of vague concept" of grooming the backlog. The act is defined as something that has been mostly the domain of the Product Owner, but should spread to be a team activity where the Product Owner is an integral part. Hesse promotes eliciting team feedback both on priorities and on story content. Hesse also provides a short list of questions that the team can be asked in order to make the act of Backlog Grooming successful. An important part of this post is the guidance regarding Technical Debt. Product owners can make the process of prioritizing Technical Debt much easier by explicitly asking questions about its existence.
Favorite Snippet -
"Continue to challenge the team as there is likely ALWAYS something that can be improved in your Product’s code. You as the Product Owner will need to ultimately weigh on if it will return the highest value to users/purchasers, but it is very important to chase these items out."


Wednesday, November 27, 2013

Welcome To The Roundup

Welcome to the Agile Roundup blog. A practitioners guide to opinions, observations and comments being expressed in the agile sphere by not just those who coach or consult on agile projects but also those who work in the trenches every day. The practice of agile, whether it is scrum, kanban or XP or any other exotic flavor of those always seems to evoke strong opinions,  ranging from dogmatic to pragmatic. This blog aims to provide a consolidated list of these opinions along with a short review of each to give you a preview of the posts.

Buffalo Roundup

Blogs like Mike Griffith's Leading Answers, Peter Saddington's Agile Scout and the agile biggies like Mike Cohn will be regularly featured. As an agile practitioner for almost 10 years, there will be some personal opining that I will indulge in, but this is mostly a round up of varying opinions in the agile sphere. Looking forward to sharing with, learning and hearing from all who stop by.