Tuesday, December 30, 2014

Retrospectives - Objective Vs Subjective

Traditionally Agile teams run retrospectives to facilitate learning, development and improvement of the team. My teams have been doing the same over the past ten years. We have tried multiple different formats to get the right outcomes. We have been through it all and we have all been through it - lack of participation, finger pointing, irrelevant topics, lack of prioritization of issues, many a time one of these problems or another hinder the effectiveness of a retrospective. Recently my team moved to a more objective retrospective from a completely subjective form of retrospective.

Subjective Retrospectives

The most common form of retrospective employed is the subjective form. This shows up in numerous variations. It consists of collection and listing of ideas/topics, prioritization, either by moderator or by the participants via voting, discussion and finally extraction of action items. This method, as you can see can range from almost autocratic to a fully team driven setup. There is a middle way, which I like to call guided setup where the facilitator coaxes the team along through the process.


Autocratic Guided Team Driven
Team Lead/Scrum Master/Coach comes up with list of items to be reviewed during the retrospective. Team Lead/Scrum Master/Coach helps seed ideas for discussion and encourages team members to add topics for discussion. Team creates list of items to be discussed with every one having equal access to introducing topics.
Team Lead provides the priority of topics to be covered in the retrospective.Team Lead helps the team prioritize the topics to be discussed.Team votes on the list that they have prepared and generates a prioritized list.
Team Lead presents his/her thoughts on the topics and prompts discussion/feedback on these topics. Team goes through the topics in priority order and Team Lead helps seed discussion if no discussion seems to emerge organically. Team goes through the prioritized topics and discusses/reviews each item to generate next steps.

Regardless of which of these subjective retrospective methods are used the most important piece is to derive action items and to have individuals be responsible for the completion of these. From a casual reading of the above table, it would seem that a team should never use the Autocratic model, should sometimes use the Guided and almost exclusively use the Team Driven approach. That maybe ideal, but unfortunately, is not real. Depending on how mature the team is, any of these approaches would be appropriate. A team with little agile experience might actually benefit a lot more by employing the Autocratic model as they might need more externally imposed discipline and help identifying the issues and the priority of those issues affecting their agility.

Objective Retrospectives

My team has started using metrics for retrospectives. We look at our scatterplot which plots our stories along the axes of dates and days taken to close the story. We then, talk about the stories that are the outliers on the higher end and figure out why they took longer than other stories. This ends up becoming a very direct discussion about why things are taking longer than they should and exposes process inefficiencies very explicitly. I found that this helped the team identify direct impact action items that improve the team's efficiency. For example in the plot below, the stories in the red circles are the ones we would concentrate on in the retrospective.



Objective retrospectives do have the side-effect of the team trying to game the system to make the numbers look good. That, in my opinion is not a bad thing if you choose the metric you are using well. I find days to finish a story to be a good metric as in order to make it look better, your direct options are to either create smaller stories or reduce the number of items you are working on. Both of these are positives in any agile system. Lets say you chose a different metric, velocity for example, gaming the system there could be achieved by overestimation of stories. The idea is to pick a metric that reveals inefficiency and making that metric better improves the team overall.

We did notice an issue with the objective retrospectives. There are certain things, that dont show up as data points on the scatterplot. There are both positive and negative subjective comments that are left over to be covered after the objective retros are done. The team going forward is now doing a split review where we start with the objective and cover what is slowing down progress and then do a shortened subjective Team Driven retrospective to cover any other topics that need to be discussed.

Finally...

Regardless of the method you employ, it is the willingness of the participants to improve as a team that is critical. That is why sometimes the Autocratic or Guided subjective retrospectives might be the right place to start for teams new to retrospectives as a tool for improvement. Objective retrospectives make sure that you talk about everything that is slowing down the team's work. The priority goes to the issues that create the greatest slowdowns and you can easily see the results the next time you review the data. Subjective retrospectives still have their place, but a mature team should be able to derive most of the value out of a retrospective via the objective method.

Wednesday, September 24, 2014

Are You Experienced - How does UX fit in with an Agile team?


UX has in many cases been an afterthought on fast moving projects. There are distinct ways to approach the integration of the user experience process into the product development process and we will explore a couple of these here. To get more insight, I interviewed two UX designers that I have worked with to get feedback on how two different styles of integration affect them, the teams and the product as well. Details of what seems to work and what does not are presented below.

The least effective approach towards UX that I have observed is the retroactive approach, where the rest of the development process is agile, but interaction with the user experience group is in a waterfall manner. Team produces a product as the business analyst and/or product owner specifies it and then it is sent over to the User Experience group for evaluation. UX makes recommendations and based on the time available in the project or whether the dev team has moved on to other features, the recommendations are implemented or put on the backlog for "future".

The second approach is also that of UX as a service but more in step with dev teams. The UX group advises the analysts and works with them during the initial design phase of the project. There is a primary resource assigned to the team that can be reached out to at any point of the development process. The primary resource attends sprint reviews and gives feedback to the product analysts, if they see any need for a design change. This is a much more "agile" approach as it makes it possible for the team to get feedback, at least at the end of every iteration.

The third approach is the one where dedicated user experience resources are a part of the team. They are embedded and function just like every other member of the team, being involved in stories from kickoff to reviews. They are able to provide constant feedback and get an idea of the technical constraints the team is working under. At the same time the dedicated resources are able to provide a slight paradigm shift in the mindset of the team. The entire team can benefit by becoming slightly more user focused as that is the perspective the user experience folks use to look at the product.

I talked to a couple of folks that I have worked with to get their feedback on the last two approaches outlined here. Lauren Martin and Bruno Torquato agreed to participate and help me out in drawing out the distinction in outcomes from the two approaches. Here are the advantages of both approaches as outlined by them.
  • Advantages of UX as a service
    • Creative Inspiration  - Lauren points out that being in the same space as other UX designers helps promote an environment where since everyone is involved in a similar creative activity, creative inspiration flows a lot more freely. This is harder to attain in an agile team setting where you are separated from the broader UX team/department.
    • Mentoring and Sharing - Working as one group providing a UX service, allows for opportunities to mentor less experienced team members and also the ability to share ideas and discoveries. "Cross pollination of ideas" according to Bruno is more natural and less forced as it has to be with UX being embedded on agile teams.
    • Planning and Execution - Lauren feels that it is easier to create plans and help with the long term execution of these plans. Also there are fewer ad-hoc requests from the team that could potentially derail the longer term plans,
    • Objective Perspective - "Outside perspective can give you space to provide insight", says Bruno. He believes that the deliverables that he provides are not "colored by the immediate needs" of the team when working in a UX as a service mode. It allows the designers space to provide insight that might be lost with the embedded perspective.
  • Advantages of Embedded UX
    • Greater Visibility and Understanding - There is increased visibility into the processes used by the designers. Lauren believes this helps the "team have a broader understanding" of what designers do and how they get to the resulting deliverables.
    • Team Ownership - Embedding user experience designers in the teams helps the team own the user experience as a collective. This enables Bruno to disseminate his "perspective and have the rest of the team take ownership" of the design as well.
    • Realistic Expectations - With the increased visibility and understanding come more realistic expectations from the team. It becomes easier for the team to understand whet the designer is shooting for. Rather than finished full scale designs being passed to the team, designers can work on a small scale where expectations are clearer.
    • Immediate Iterations - Desk checks and story reviews help make sure that design can be iterated upon quickly and at times almost as soon as it is implemented. Sometimes, this is before it is implemented, if the team has technical limitations or any other obstacles that come up, the designer can help remove those or modify the design as needed.

Both Lauren and Bruno made excellent points that can not be summarized simply as advantages of these systems. They both at this point work as embedded designers an agile teams. Lauren remarked how when being embedded, at times "creative flow is almost impossible to attain". On her team, the two designers have had to split responsibilities between "just in time and work ahead" responsibilities to make sure they can maintain creative flow and respond to team requests.

Bruno makes a point about the being within the team lays "more importance on developing relationships within the team" and the fact that the dynamic within the team  can help with having more momentum with the project. Another advantage of team specificity mentioned by Bruno is being able to adopt process to product , i.e. use the ideal process based on team and product type.

Last bit though, my favourite quote from the interviews -
"It still depends on the team, and the system does not matter as much"- Lauren.
Rings very true, raising the team's consciousness is more important than the system the UX folks work in. 

Wednesday, August 20, 2014

Leading Agile Teams : Effective Process Improvements On Teams

This is the last post in the Leading Agile series based on the four interviews with team leads at my organization.  Below are the responses to the question "What changes have you made in processes on the team that have helped the team become more agile and/or productive?".  There were multiple improvements pointed out by the participants, but the graphic below shows the ones that they considered to be the ones that had the biggest impact.


Other changes that the interviewees mentioned as having an impact -
  • Involving UX designers earlier in the process
  • Switching to a purely electronic board from a physical board
  • Having cells own story creation
  • Developing leadership within the team
  • Moving merging of code from separate departments much earlier in the process.
  • Blurring the lines between teams that share the codebase.

Finally, a heartfelt thank you to the interviewees for their participation. It was a lot of fun putting this together and I have learned a lot through the interviews and the reevaluation of our conversations. Thanks Again.

Tuesday, August 12, 2014

Leading Agile Teams : Conditions Teams Thrive In - II

In the last post we saw the infographic that included comments from four of the Team Leads that were interviewed for this series of posts. Here are some thoughts on the responses that were gathered.

Yvette Gaitan

"When the team has the proper tools available to do its work. Adequate communication from upstream teams about changes so that we are better prepared. Communication and team-wide awareness of the correct priorities in a space where priorities are constantly changing."

Yvette's team is often downstream from numerous other development teams. That explains the emphasis on communication both within and without the team. Agile environments are characterized by change and the ability of the team to adapt to such changes. Yvette's team seems to do this well as long as the priorities have been well communicated. They seemed to have understood that change is inevitable, but getting a heads up puts them ahead of the game.
Specialized tools that take the tasks that the team performs and automates them are always beneficial and welcome, regardless of team, methodology or industry. If the team is in unique situations and is given the bandwidth to come up with tools and processes that make them more efficient, the effects can be long lasting.

Michael Longin

"Informal attitude in the team room, balanced with structure through formal plannings, reviews and retrospectives.  Knowing that we are set up for success, but failure is OK.  Provide a safe failure environment and help people while they are failing.  Feeling of influence in the product."

A team working together day in and day out develops its own personality. For the team to develop both informal interactions to cope with the high pace and formal attitudes to achieve structure as Mike points out. Mike talks about a safe failure environment and contrasts it with being set up for success. This is important for the team and the organization as a whole. This means that plans are set up so that the team succeeds and there is no organizational backlash if the team happens to fail. Another important snippet here is "help people while they are failing", as signs of failure and opportunities to avoid/readjust are often present long before failure actually happens. 
Most development teams I have talked to mention this last point of having influence in the product. This is probably the single most empowering notion I have come across when talking to my colleagues. Influence leads to ownership, which helps make the team excited about the problems they are solving and the solutions they are creating.

Anonymous

"We work well under stress, specially when something has gone wrong. Team closes a lot of stories towards the end of the release. It helps the team to see where it stands in comparison to other teams."

Here we see a team that is under pressure and as a result has learned to deal with it by coming together and pushing hard. When things go wrong, teams come together and tackle the problem head on. This team seems to do that. What might be missing though, is the same coming together to come up with processes to prevent things from going wrong. The team here also seems to have a competitive spirit and takes pride in excelling especially in comparison to other teams in the organization. 
While this team is obviously working hard and producing results, there is something amiss in release planning for the team if end of release is when the pace picks up. This is not ideal. Teams should not need stress to perform well, in fact, stress, although sometimes unavoidable should be prompting reflection and change in team behaviour.

Mariana Sabogal

"Having a collaborative Product Owner is a great help. Team's feedback taken into account during planning, specially the technical perspective. This gives the team feeling of ownership."

Mariana reiterates the point that Mike has also made. Team having an influence in the product empowers them and gives them ownership.  Making technical feedback a part of the planning is a great way to get technical debt prioritized as well. Both Mariana and Mike talked about being closer to the customer and having input into the product as being a great components of getting the most out of teams. It would be good to clarify here that these are independent observations.
The importance of a collaborative Product Owner cannot be undervalued as Mariana notes. There are ample examples of a non-involved or no-collaborative Product Owner running teams off-course and being an impediment instead of a problem solver. Mariana feels that whenever she is working with a Product Owner that works well with her team, performance and productivity of the team is very high for that time period.

Friday, August 1, 2014

Leading Agile Teams : Obstacles and Improvements


Leaders of agile teams often see some common issues crop up on teams. Very often, the issues faced by a team are particular to the situations the team finds itself in. The same applies to the leaders of these teams. They face unique obstacles depending on the teams they are on. Being a team lead is about adopting new practices, modifying existing processes and removing unnecessary clutter from the team's systems. I asked four team leads about the obstacles they face and the changes they have made on the teams to make the team more agile and/or productive. These are the same folks that participated in the last post. Below are the responses.

What have been the biggest obstacles that you have faced as a lead?

"Acting as a manager, without being a manager.", according to Mariana has been one of the biggest obstacles for her. She does feel that she has been "Lucky to have been on the team for a long time". This has helped her garner the respect of her teammates and which in turn has helped her fill the "manager" role. There are other little things that she feels hold her back - Not having "admin rights" in issue tracking tools, having to keep track of PTO for team members and other small added on responsibilities.

Mariana sees the ambiguity of an agile team lead's responsibilities as an issue. Is she a manager? If so, should she be given rights to perform other managerial functions? Is she a project manager? If so, should she have full admin access to project management tools? The ambiguity in role definition leads to the ambiguity in rights(admin or managerial) provided. This is not necessarily a negative though. The ambiguity leaves space for Team Leads to better define their own roles according to the needs of the team.

"Keeping the team motivated" for our anonymous participant is one of the bigger challenges. Another major challenge for him is to "distribute workload within the team evenly" and "balance capabilities within the team". He feels that "high, mid and low level performers" should be teamed up with each other on projects to promote knowledge transfer and help low performers improve.

Keeping a large team motivated can be a tough ask for any leader. It is rightly pointed out as an obstacles as the variety of personalities on agile teams is often large and what helps them get motivated is different in case of every person. Agile throws a bunch of individuals into a team room and they have to sink or swim together. The desire to help them work together in the best possible scenarios is another challenge that is well noted here.

"Recognizing that I am the leader, not the secretary" for the team was Mike's biggest obstacle that he feels he has overcome. He says that Team Leads need to "understand that the team needs your direction". The have "to be the de-facto leaders of the team."

Mike is an experienced LPE and understands his role well. He seems to understand the value of a strong leader on the team and the importance of the direction that leader provides. Agile leads are 'servant leaders', but if you let the former part of the phrase dominate, the role becomes more secretarial rather than one in a well balanced leadership capacity. Since the Agile leads usually emerge from within the team, it is a tough concept to grab at the onset. Emerging as a leader of your peers, who you are technically on par with is a skill that every agile lead has to slowly develop.

"Resistance to change within and with-out the team" has been one of the greatest challenges for Yvette. "Effective communication of constraints to other teams" that her team supports especially in terms of "being recognized as a part of development rather than support for deadlines".

Yvette's team is client facing and any process changes proposed are often heavily scrutinized because they can have deep impacts. As a true lead though, she has not been afraid to propose and make these changes. Although the team can be an entity onto itself, it often, especially in Yvette's team's case, has direct upstream dependencies on other teams. These teams all have the same deadlines and while other teams are working towards their deadlines, Yvette's team is coming up with ways to avoid a time crunch due to the dependencies.

What would be one thing you would change in order to improve your team?

"Get the team more exposure to the customers", says Mariana is the primary change that she would make to help the team. She says "it adds meaning to the team's work".

Mariana touches upon an aspect of agile that has not been as broadly explored at many organizations. Getting every member of the team to understand the customer's needs and pain points gives the team a stronger connection to what they are building. This in turn helps them make better decisions regarding design, prioritization and even to some extent implementation.

Shortening "the time it takes from a story to move from code complete to close" is the critical change that the anonymous participant would like to see on his team.

Projects where there is a direct imbalance between how long a story spends in engineering vs testing can see the backlog getting stuck in one stage of the development cycle. There are multiple strategies to counter this, and the one that would work best, would depend on the team itself.  Some strategies that I have seen work successfully have been pairing Devs with QAs to help develop the automation for the tests the QAs write, introducing more tech debt type items that the devs can work on, while QAs catch up, or have strict discipline with keeping the number of total stories in progress limited. Only criteria for the strategy adopted, it has to suit the team well.

Mike believes that getting "TRADE(Yvette's triage team) coverage" for his team and getting help with "external escalation management" is the primary thing that will help them improve. Mike also mentions "getting away from UI automation" as another major improvement that can be introduced.

Having another group triage issues to determine if the issues are real functional issues is a double edged sword. It protects the team from unnecessary interruptions, especially from issues cause due to product knowledge gap, but at the same time pushes the responsibility of closing that gap towards the users instead of pushing the product designers to improve the usability and to make the product more intuitive to use.

Yvette believes that "greater cross-training" is the one major improvement she will make to her team. She also wants to "make the check-in process for customs water-tight".

Yvette's team works in a high pace environment and cross training often takes a back seat. Her team might benefit from pairing techniques to get team members comfortable with working in different areas. CI and a stable build/code check in process is at the base of all successful agile engineering practices. Getting another team(or department in this case) to adopt agile practices can be a tough sell, but at the same time, having a partially agile organization can be an impediment to whichever agile team has to interact with a non-agile part of the organization.

Once again, it was great to review all the information that was passed on to me by this varied group of leaders. I have learned a lot from their experiences and we have had some very interesting conversations with them about the same. Once again, hoping to continue to have these interactions with the same folks and a larger group.

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