Interview with Diana Larsen

It has been our privilege to interview Diana Larsen who is co-founder of Agile Fluency™ Project, Author, Speaker, Agile Coach & Agility Consultant. She is a Visionary Pragmatist and helps to build capability and capacity in teams and organisations.

We discussed about Agile Fluency Model, Agile Standup Meetings, her idea of a healthy team and Agile Retrospectives with her in the interview.

Q1. Improv activities can bring improvements in Agile standup meetings. Elaborate a little on this with your experience.

Diana: I’m not trained in Improv techniques, and don’t agree that these activities contribute to standup meetings. They may be wonderful and fun activities for team building at other times, but standup offers the most benefit when they are kept brief (30-60 seconds per team member) and to the point––sustaining communication about the state of the work. It helps when team members know the questions ahead of time and come prepared to answer them succinctly. I recommend that each person write their answer on an index card to bring to the meeting.

However, the “three questions” don’t need to always be the same. Instead of improv activities, for fun and variety insert new questions from time to time, e.g. every other week or monthly. As you try new questions, make sure they stay focused on the work. Some possible variations:

Set A. (The Classic)

1) What story did you work on yesterday? Who worked on it with you? 2) What story do you plan to tackle today? Who will you work with on it? 3) What obstacles, if any, do you anticipate to finishing?

Set B. (Shared Learning)

1) In the work you did yesterday, what did you learn that could help the whole team? 2) What do you hope to learn today? How will you share it with all of us? 3) What gets in the way of your learning?

Set C. (Finding Help)

1) What helpful resources (e.g., websites, books, articles, repositories, team member expertise, etc.) did you access yesterday for your work? 2) Where will you look for help today? 3) When have you found it difficult to find helpful resources? What gets in the way?

Set D. (Achieving the Plan)

1) How did you help the team move toward our iteration plan yesterday? 2) How will you help us move forward on the plan today? 3) What will impede your progress? 4) On a scale of 0 (no way) – 5 (super confident), how confident are you that we will complete all the work in our iteration plan?

Set E. (Continuous Integration)

1) What did you commit yesterday? 2) What do you hope to commit today? 3) What hinders your ability to continuously integrate your work today?

–– By the way, the path to removing any obstacles, impediments, hindrances, or problems should be discussed separately outside of the standup meeting.

Q2. What defines a ‘Healthy’ team?

Diana: A healthy team has a shared work focus–delivering a feature, designing a product, serving a customer domain. The members know the outcome they have come together to accomplish. They also have learned to raise difficulties, conflicts, and potential “elephants in the room” while they are small, even though it may be uncomfortable to do so. They’ve learned the value of working together for improving their product quality, their work process, their teamwork, and their communication with those outside of their team. If they don’t hold regular, useful Retrospective meetings, they find another path toward continuous learning and improvement. Team members support each other.

Q3. What motivated you to work around ‘Agile Fluency’ Model and present it to the Agile Community?

Diana: James Shore and I had been working closely together for several years. During that time we had many discussions about Agile values, principles, practices, and healthy teams. The actual trigger was a conversation we had about how to improve a workshop we were presenting. That conversation led us to explore the idea of fluency in agile practices, and how those might be different for various situations. We decided to share our ideas as they developed with our local Agile meetup groups, at regional conferences, and with practitioners whose work we admire. When we began getting consistent feedback that the Agile Fluency Model was ready for publishing more broadly, we worked with Martin Fowler to make it available through his website. That was August 2012. In subsequent years, many folks shared with us their stories of using the model and we developed additional resources at our clients’ requests. Those new experiences helped us to learn more about how the Agile Fluency Model could help teams and organizations, so we updated the whitepaper earlier this year with new content. It’s available from the home page of our website http://agilefluency.org at the click of a button.

Q4. Agile Retrospectives can make good teams great. How is that possible? At times, it becomes difficult to make young practitioners understand the significance of retrospectives. Please suggest ways to overcome such situation.

Diana: In most cultures there is a proverb that says something like, “There is always room for improvement.” That is true for software teams, as well as other instances. When we stop learning, we stop growing. When we stop growing, we die. Regular Retrospective meetings are a way (not the only way, but one good one) to ensure that teams are always focused on what they can learn about doing better and how they can experiment their way to improved product quality, improved work process, improved teamwork and team member relations, improved communication with parties outside of the team, and on and on.

Younger team members often have had an unsatisfactory relationship with formal learning and believe they have been hired because they already “know it all.” And they probably are very intelligent, knowledgable people or the company wouldn’t have hired them. Thus, they can become reluctant to admit there are things they don’t know. But the world, particularly the world of software, is changing too fast to rely on past knowledge. We must open ourselves to what we don’t know yet and be prepared for continuous learning on many levels. Holding Retrospectives helps to support that effort.

 

Diana Larsen is the author of Agile Retrospectives: Making Good Teams Great, Liftoff: Start and Sustain Successful Agile Teams, and Five Rules for Accelerated Learning. For more than 20 years she has worked with leaders to design work systems, improve project performance, and support leadership and enterprise agility.

An active speaker and contributor to her professional community, Diana has contributed in leadership roles to the Agile Alliance, the Organization Design Forum, and the Agile Open Initiative.

 

Interview with Andrew Hunt

This time we bring you conversation with a Programmer turned consultant, author and publisher – Andrew Hunt.

Andy is a founder of the Pragmatic Programmers and Agile Alliance. He is one of the original co-authors the Agile Manifesto, and authored several books not just on programming, Agile methods and learning, but also on science fiction and adventure. An active musician and woodworker,  Andy looks for new areas to explore, learn and share.

In this interview, we discussed about what will Agile be beyond 2018.

Q1.  It is almost 17 years ever since Agile has came into existence. Do you believe it has achieved what it aimed for, by the 17 precious minds?

Andy: I think the movement was very successful in some regards, and certainly raised the overall discussion and level of awareness of how we should and should not try to develop software. Some particular practices have seen widespread and successful adoptions, and that’s all great.

However, many organizations are still underperforming and are not able to generate value from their software development projects. They aren’t being effective, and don’t understand what the problem is. They still don’t understand what it means to be Agile.

Worse, perhaps, the major “Agile” methods themselves have not appreciably changed in all these years. The Agile methods themselves don’t seem to be very Agile, ironically.

Q2. Have you ever been disappointed by the way Agile is being implemented in any organization/team and went off track? Please share your experience.

Andy: Constantly. I’ve met teams who’ve claimed “we’re agile, we use Jira/Rally/VersionOne!” Teams where the continuous build runs on Friday. Where version control check-ins only happen once every two weeks. Where the version control system in use is Microsoft Outlook(!). Where the Stand Up meeting runs forty-five minutes. Where rough estimates with insufficient data are taken as contractual, binding promises.

I worked with a team once who was so intent on perfecting their process (XP in this case), that they practically used User Stories on cards to decide on where to go for lunch. In their zeal for Agile adoption, the process itself became the focus of their work, instead of merely a means to an end to deliver product.

Recently I had some developers tell me, with a straight face, that they weren’t allowed to do incremental or iterative development. They could only deliver once, as “gold master” at the end of a multiyear development project. No review, no feedback before then, not even internally. I tried emailing them last week to see how it went, but all the emails bounced.

Apparently they are no longer in business.

Q3. Certification or Experience – it is much discussed among Agile practitioners; what can take anyone’s career to next level, according to you?

Andy: Certification is nonsense. It is a very poor proxy by which to judge past experience or future performance. There is absolutely no substitute for experience, certainly not simple course attendance, or performance on a low-fidelity, written test instrument. There is plenty of research in learning transfer that confirms that common certification assessment approaches simply don’t work.

The whole game of software development is about communications and learning. How well do you communicate to other developers? To the users? To the project sponsors and executives? How fast can you learn? Not just tech, but the evolving system, the dynamics of the team, of the user’s experience, etc.

To get your career to the next level, those are the areas you need to work on. Improve your ability to learn quickly, thoroughly. Improve your critical thinking skills. Learn to be a better listener.

Those are the sorts of things we need assessments on.

Q4. Do you find any myths floating in the community about Agile methodology? Please share 3 such myths that are critical to be eliminated.

Andy:

  • “This time it will be different.” Oh really? What have you changed? What are you doing differently? Agile is about embracing change and using it for competitive advantage. If you and your team haven’t changed anything—your process, your techniques, your skills—then you’ll struggle to even get the same results as last time. More than likely, results will be even worse.
  • “Best practices.” Best for who? Under what circumstances? In what context? There is no such thing as a general “best practice,” everything depends on context. For example, in what quadrant of the Cynefin space does your problem lie? Different types of problem spaces require different approaches, and a best practice in one area can easily be disastrous in another.
  • “Just do this process.” It is very pleasant to think that if we could just follow this particular process that all our problems would be solved. But that’s an exceptionally naive approach. A process is only one tool in the toolbox. It can help talented, skilled practitioners achieve their goals, but no process is a substitute for thinking. Or for skill.

Q5. What does real Agile mean? If you have to redefine it and introduce back to the community, how would it be?

Andy: Agile is not something you do. Agile is not Scrum, XP, Lean, or the ironically-named “SAFe.” Agile is not Jira. Agile is not git. Agile is not Docker, or DevOps, or functional programming, or any other particular tool or technique.

“Agile Development uses feedback to make constant adjustments in a highly collaborative environment.” (Practices of an Agile Developer, Subramanium & Hunt).

It’s all about feedback. From unit tests and TDD, from users and live systems in the actual user’s context, from fellow developers, from future maintainers. Being Agile means seeking constant, real-time feedback, and acting on it immediately.

A common metaphor that’s used relates Agile to steering a car: a frequent cause of crashes from new drivers is overcorrecting. An inexperienced driver will catch the shoulder of the road and yank the steering wheel violently to the other side, resulting in a crash. And so it is with feedback: small corrections, frequently applied, will steer the project in the right direction. Rapid and violent course corrections can easily result in disaster.

Q6. Where does Agile go from here? What do you wish for it beyond 2018?

Andy: I would like to see an emphasis on individuals and interactions over processes and tools. That’s the first item on the Agile manifesto (agilemanifesto.org) and apparently still one of the hardest to get right. Let’s start with that and really, actually, do it.

Stop abdicating to popular tools, methods, and fads. Do what works for this team, in this context, to produce some small bit of business value constantly. Ship continuously. Learn and improve, continuously. That’s what it’s all about. That’s all you need. And that’s what we’re advocating in our work with The GROWS Method™ (growsmethod.com). It’s early still and there is much work to be done, but I’m convinced it’s the only viable way forward.

Q7. Please share your insights on concept of Pragmatic Thinking and Learning.

Andy: Pragmatic Thinking and Learning is a book I wrote in 2008, based on several years of research, presentations and workshops I had given. It covers a number of techniques to help learning and creativity, including things like mindmaps, reading techniques, how to take advantage of hypnagogia, and other bits and pieces from cognitive and neuroscience. It’s a collection of good ideas that seem to be helpful.

Q8. What would be your message for young generation of Agile practitioners? Please share some Do’s and Don’ts.

Andy:

  • DO get feedback from all the things. Code, people, process, whatever
  • DO favor individuals and their dynamic interactions over any static processes and tools
  • DO take small bites, always
  • DO change one thing at time
  • DON’T guess. Experiment and find out
  • DON’T keep code or process that’s passed its expiration date. Throw out code you’re not using. Prune processes relentlessly
  • DON’T do fortune-telling.

We are terrible at trying to predict the future, whether it’s an estimate or guessing how a design or architecture might evolve to meet future needs. Don’t guess the future, we’re bad at it (as a species). Instead of trying to make software maintainable or extensible, make it replaceable. Make it easy to throw away and replace with a more appropriate solution when the time comes. Because then, and only then, will you accurately know what you need.

Don’t guess. Know.

 

Andrew Hunt writes books on software development and science fiction. He co-authored The Pragmatic Programmer and many other good reads including Learn to Program with Minecraft Plugins, the popular Pragmatic Thinking and Learning: Refactor Your Wetware and the Jolt-worthy Practices of An Agile Developer. His science fiction books include the novel Conglommora and Conglommora Found. He was one of the 17 original authors of the Agile Manifesto and founders of the Agile Alliance. He and partner Dave Thomas founded the Pragmatic Bookshelf series of books for software developers. He also plays the trumpet, flugel horn, and keyboards. Find him online at toolshed.com.