Agile and Beyond had it’s 6th conference on April 30 and May 1 of 2015 and I was lucky to get to go and learn some “new to me” things. I recommend that
I will write more about each topic in later posts but I did want to give a small summary for each presentation I was able to attend.
Leaders at All Levels
Esther Derby opened the conference with a great keynote, that discussed a change from the traditional levels of organizations Strategy, Direction and Coordination, and Performers to Steering, Enabling, and Doing. She then broke it down by three categories of responsibility of leaders; Clarity, Conditions, Constraints.
Leadership is the ability to enhance the environment so that everyone is empowered to contribute creatively to solving problems – Gerald M. Weinberg
Clarity defines what you are working on, how it fits into the bigger picture, and who the customer is. Workers can’t make great products for customers if they can’t get the necessary information.
Conditions are the means for the people to do their work and the support from the organization to do the work. If the organization does not support the workers to be great, they will stay mediocre.
Constraints tell people what they should and should not do and define the boundaries of autonomy. Too rigid of constraints becomes too regulated and routine, where as too much enabling can lead to chaos.
Organizations should prioritize “coherence over consistency”. What works for one person or team may be too much or too little for another group.
The original purpose of a hierarchy is always to help its originating subsystems do their jobs better. - Donella h. Meadows
How Crayons & Post-its Can Alleviate Data Distress and Object Obscurity
Carol Treat Morton and Samah Majadla ran a workshop to show how simple tools like Crayons & Post-its can be used to focus the project’s attention and layout an object map that everyone can understand.
The workshop focused around two real users that were trying to pay for their parking at a meter system. They provided us with some footage of two users trying to pay for parking with a mix result of success.
The first technique they taught was to take one of the users actions and break it down into individual steps on Post-its and then layout in a timeline. This allows you to easily see and identify the pain points of the process for the user.
Then based on the constraints of the client, you can limit the scope of the work to only things that can be changed. In the workshop, the client would only allow us to change the software, because changing hardware would be too costly. This allowed us to focus our attention just to a specific part of the workflow, and ignore the problem areas that dealt with hardware.
Finally they then taught us how to take the action based workflow cards and turn them into object’s that represented the scene. These objects become reference points for the entire team and a common language for talking about the problem.
Overall these techniques were really helpful for me to visualize the problem and made it fun. Although we used markers instead of actual crayons, the big point is to move away from black and white and use color, because it can be fun and attention grabbing.
Putting the D&D in TDD
Guy Royse talked about Katas and how the traditional bowling, credit card validation and Conway’s Game Of Life don’t always push developers to test all their muscles.
The Kata he introduced to everyone is called the Evercraft Kata, in which you work in pairs to ping-pong TDD your way to make a Dungeons and Dragons system.
Although I didn’t necessarily learn anything new for TDD, I did affirm to myself that I do understand it. Also I was able to pair up with some college seniors and help teach them TDD. With the luck of a percent roll, I was able to win a Pound-O-Dice
Agile is for Wimps: Top-Level Software Development in the 21st Century
Alistair Cockburn gave the second keynote of the conference and sadly I only saw the tail end of the talk. Alistair points out that the Agile Manifesto can lead to wimps with lack of deadlines and contracts, but if we go back to the heart of Agile we will deliver what our customers want.
In his talk, Alistair talks about the three stages of a feature or project as the learning stage, the value stage, and the tail stage. In the learning stage you are not delivering much but gathering all the necessary information. In the value stage you are delivering quite a bit in a short amount of time. In the tail stage value delivery starts to slow down.
Sometimes it may seem that you can’t ship without the full feature, but if you “trim the tail” and ship, you will be delivering high value in a short amount of time. Additionally If you break down the features into these stages, you can prioritize them to deliver more value over time, instead of focusing on one feature at a time.
Gamifying Retrospectives for Distributed Teams
Dana Pylayeva gave a workshop about running retrospectives for distributed teams. Each table chose to be a different city around the world, and we retroed the first day of the conference and then using some simple technology, we were going to be able to simulate being distributed across the world.
Trust drops instantly when teams are not co-located.
Although the workshop ran out of time, I did learn a few “new to me” techniques. One technique was to use Story Cubes to help build a story of what happened for the portion of time being retro. Another technique used a timeline to layout what happened, which like the workflow workshop, can help visualize when and where things went wrong or right.
The big thing I realized after the workshop, is that I have been in many retros where the feelings are the first thing to come out, but as Dana points out at the beginning of retro we should be focusing on data and not feelings. I think this is why it can be really hard for some people to discuss hard topics at retrospectives.
Esther Derby, writer of Agile Restrospective sat at our table and shared with us how she used to use fortune cookies to get her team to share what happened that week.
Talent Development 3.0
Matt Barcomb and Rachel Howard gave a really awesome presentation about lifecycle of talent in organizations. The stages of talent are Courting, Auditioning, Growing, Connecting, and Leaping.
Courting is about how you find new great talent. You should always be hiring, by sending the right people out in the community and having conversations with new and different people. Your already great talent can weed out the bad talent faster than a talent scout.
Auditioning is about how you validate the new talent. Use take home or all day projects to push them to their limits and see that they are perfect for your team.
Growing is about keeping your talent great. Stop trying to measure their performance and start measuring their growth. You should be enabling your coworkers to learn and achieve more than when they first arrived.
Connecting is about getting your talent to improve the community. Whether it is the organization or external communities, getting your talent to connect will show how awesome your group really is.
Leaping is about letting go of your talent. You should be building a conduit for talent to constantly develop and when they reach the point where they can’t go any further in your organization they should be able to leave. By building this talent pipeline, the organization becomes resilient and capable of losing anyone in the organization.
Building Software Craftsmen
Steve Ropa gave an enlightening talk about how to train new developers into Craftsmen.
In his talk, he describes an apprenticeship that lasts from 3 to 6 months, in which they learn multiple languages, work in groups, and pair constantly with Journeymen and Masters. He talks about how our universities are failing us and how we can take charge and make developers ourselves.
This talk rang home really well for me, because at Detroit Labs we have an apprenticeship program, that has some of these components but I don’t think it has all of them.
Before I went to this talk, I had wanted to write a post about the idea of treating new programmers like old time apprentices or like electrical apprentices, and this talk revived that idea even more.
Shifting value into high gear
Mike Edwards shares his heartfelt story of how after his dog passed away while he was on a trip, a WestJet employee gave him a hug and took the time to hold an earlier flight to get him onboard and on his way home. This was a “Wow” moment for him. Most companies give us some value, but most don’t wow us.
Mike talks about how we need to be more connected and have autonomy in order to wow our customers. Traditional hierarchy, has the customers representatives on top, followed by some management, and then with the workers. Mike suggests we change it such that the workers are connected with the customers and the management enable the workers to best solve the customers problems.
In the case of WestJet, all the employees are considered owners of the company and so they have the ability to go above and beyond to take care of the customer, even if that means getting them on a competitors airline because of delays or cancellations. By trusting your employees to do the right thing, they will go beyond the required steps to make sure people are treated well.
There’s No I in Team, But Should There Be?
Diane Zajac-Woodie ran a panel of some really great speakers about the topic of Generalist and Specialists. I was hoping for a different talk than what it was, but I did get a few great points out of it.
Most people have a pi shape, with more than one specialty, a specialist just happens to have a much narrower top than a generalist. As you zoom out of a specialists T-shape it becomes more like an I or single line, where as the Generalists stays as a T.
In one of the examples given, one team decided to force all the team members to work on each aspect of the project, testing, development, business analysts, etc. In the end, everyone loved id and creates an awesome product, however they had to force in on the team and they did lose people that didn’t want work that way.
I asked the question, “Can you teach generalist, and if so how?”, in which the answer didn’t necessarily answer my question but did give me some great insight. If a person wants to be a generalist, they are going to have to learn the basics, but they don’t have to go too far into the advance or expert levels of the field. In order to teach generalist, specialists need to be present to layout some heuristics, so that the generalists don’t need to dive so far down to learn the details of every solution.
Handling interruptions during sprints
Sam Nadarajan presented a case study of what happened to his team when dealing with support cases for their product. Sam works on a project where they are shipping new releases every month and support the current production application being used.
He talks about how originally they would just add the support tickets to the same list that was being used to pull new tasks, but it grew out of hand and fixes weren’t being made in a timely fashion. They then divide the boards in two, and made one Kanban board that had the support cases and one Scrum board that had the new features, but still the team only focused on the Scrum board, because that is where all the conversation fell around.
Eventually they decided to rotate a developer each release onto the job of Ops and as problems came in that person would take on that task. When there were no support tickets left, they would be able to take time to refactor and improve the current features. Additionally as problems came up that the person on Ops was unable to solve, the team would swarm around the problem and share the knowledge.
As much as I think you should be able to have the whole team be on support and work on new tasks all the time, having a system like this in place makes for a fair environment and helps break down silos.