Timeless Agility – Hangout with Dave Moran

Ephlux talks with Dave Moran about the concept of ‘Timeless Agility’. Dave is a founder and agile coach at Agile Guide, LLC. He is an experienced software development manager, product manager, agile coach and leader/contributor in the agile community with a demonstrated ability to build high-performance teams; a key leader in guiding a highly successful organizational transformation to agile development, balancing product management and product development to maximize ROI and create “raving fans.”
Article referred in the hangout: ‘Timeless Agility’ article by Dave Moran 

Q1: Dave, your Timeless Agility post presented a layered pyramid to explain agile. Can you elaborate on this?

A1: Certainly. This model came from Alan Kelly, who wrote a book titled Changing Software Development: Learning to Become Agile.  I find that it is a useful tool to illustrate the difference between doing agile and being agile. Doing agile is represented by the methodologies at the very top of the pyramid, with Scrum – the most popular agile methodology in use today – being one of those.
Scrum is a framework for teams to self-organize and self-manage their own work. But here’s the deal: The difficulty for organizations implementing agile is that Scrum is what they see, and they end up equating full agility to a simple framework like Scrum. Without looking deeper, organizations risk hanging onto many of the same beliefs and behaviors that govern their work today, missing out on a truly transformational opportunity.
It is this transformational experience that occupies the three other layers of the pyramid –the bulk of the pyramid. It is also where we find those timeless qualities that make a lasting difference.
Let’s start at the base of the pyramid, which is a learning organization. Peter Senge wrote about five characteristics of learning organizations in his book The Fifth Discipline. They are: systems thinking, personal mastery, mental models, a shared vision, and team learning. These concepts are implemented in increasingly specific ways as we move up the pyramid.
As move up to the next level – Lean, we find that there are seven principles of lean development: eliminate waste, amplify learning, decide as late as possible, deliver as fast as possible, empower the team, build integrity in, and see the whole. These concepts are in turn implemented more specifically as we move up the pyramid. Sitting above lean is the Agile layer, which includes the four values and twelve principles of the Agile Manifesto that I won’t bore people by enumerating right now, but these agile values and principles all support the what we find in lean and learning organizations. And finally, we move to something like Scrum at the top of the pyramid, which is a specific implementation of the principles and concepts in the three foundational layers below it.

Q2: Thanks, Dave. Your article provided a brief example of these layers in action from the Agile Manifesto. Could you expand on this a little?

A2: Sure. It’s about continuous improvement. One of the principles of the Agile Manifesto states that, “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.” As a tool, Scrum provides a mechanism for supporting this principle: the retrospective. So we can readily see how the top two layers are involved.
As I stated, a characteristic of learning organizations is team learning – and in fact many of the other characteristics contribute to effective learning, such as taking a systems view and using mental models so that we can discuss our assumptions with others.
Likewise, lean principles want us to amplify learning by experimenting and leveraging short feedback cycles. This applies to both what teams are building and how they are building it. Scrum teams learn how to build solutions more efficiently and effectively by reflecting on what they can improve and experimenting with new practices. And they continually update their understanding about what to build based on customer feedback. Learning is amplified through short feedback loops that are part and parcel with iterative agile delivery.

Q3:  Great. Your article also discussed agility as something that must exist at a personal, team and organizational level.  Can you give us a little more context in terms of the qualities involved?

A3: I’d be happy to! I’ll build on the continuous improvement example. At a personal level, an important quality to possess is a growth mindset. Dr. Carol Dweck published some interesting research on this in her book, Mindset: The New Psychology of Success. An individual with a growth mindset is concerned about personal growth and improvement. If we have a fixed mindset, we have different, limiting concerns, such as how we will be judged by others. And worse, if we have a fixed mindset we hold the belief that our abilities are carved in stone, so individuals with a fixed mindset don’t value investing the time and effort in stretching and changing.
A fixed mindset causes us to seek validation, to prove that we are already smart or talented. A growth mindset, on the other hand, allows us the mental freedom to acknowledge that we don’t know everything – and that’s OK because those with a growth mindset believe that we can stretch and develop ourselves.  Personal mastery – a characteristic of learning organization – is all about being in this growth-oriented, continual learning mode.
Moving on to the team level we can see how this personal quality impacts team learning, although agile teams need to be able to take personal mastery to another level. A team that seeks to continuously improve must be open and honest with each other. We must be able to acknowledge our personal abilities and our abilities to collaborate together, where we are combining tasks and interacting in high-bandwidth ways to produce a team outcome. A fixed mindset will tend to shy away from reality, if that reality is exposing weakness.
As we move up to the organizational level, the personal qualities that enable learning must be supported across the board. Having a systems view – “seeing the whole,” respectful inquiry so that assumptions can be challenged, etc. are examples of what needs to come into play. These qualities must be modeled as behaviors by leaders in order for them to take root and become part of the organizational DNA.
It is equally important that we build in the capability to share knowledge laterally across the organization by doing things like setting up Communities of Practice. And let me state a preference that I have to stay away from “best practices.” If we are supporting continuous improvement, don’t label something as best. This can cause the unintended consequence of forcing an approach as being “best” or creating frustrating bureaucracy that must be overcome if a team wants to experiment with a different approach. I worked for a company that had a development “guide” that wasn’t just a guide, it morphed into a rulebook. Deviating from the guide or requesting a change required a lot work because there was a lot of incentive to retain and use what was regarded as proven techniques, regardless of the circumstances a team was facing.

Q4: Thanks, Dave. Since we’re talking about personal, team and organizational agility, how do you recommend that an organization start down the agile path?

A4: I think on-boarding a team or two is where you want to start. However, don’t limit learning about agile to just the team. Project managers and managers who are interacting with agile teams need to understand the underlying values and principles – since an agile team in a non-agile organization is likely to encounter some organizational “friction.” Project managers and managers are in a great position to help teams overcome this friction and start educating the rest of the organization on agile change, driving change with the rest of the organization, in fact.

Q5: That just prompted a question in my mind. Why does the rest of the organization need to understand anything about agile? After all, if the development team is delivering frequently so that key stakeholders can see the product more often, what else do they need to understand?

A5: A number of things come to mind! Generally, it is easier for executives to understand that features will be delivered incrementally; they enjoy seeing working software because it demonstrates – for real – where the team is. This is a huge advantage over being 50% complete on a project plan with nothing being demonstrated.
Other practices are harder to let go of, and are where conflicting expectations emerge. Detailing the requirements along with creating a detailed project plan up front is an example. Agile gets to work quicker because it uses lightweight techniques to outline the development effort, using a just-in-time requirements elaboration approach. Just a lean manufacturing doesn’t build up excessive inventory of goods, we don’t want to build up a large inventory of requirements at the outset with agile.
So we defer on elaborating the requirements to a time that is closer to when the team will actually be implementing the requirements. This means that we’re also planning continuously throughout an agile development cycle, and not doing it all up front. And this is where expectations must be understood – that agile teams need regular business interaction throughout the effort as well. Traditional approaches ask for a big chunk of time up front, and then the business people can go back to their regular work and wait for delivery, where they usually start outlining all of the things the development team got wrong.

Q6: Good point, Dave! That usually leads to some challenging conversations, to say the least. What about other sources of friction, such as those encountered by middle management?

A6: Well, a big change generally comes as teams move past their initial implementation and start to understand and absorb the underlying principles. Most managers strive to operate the business in ways that lean manufacturing has gotten away from, viewing each person as a resource and striving to utilize each resource as close to 100% as possible – all in the name of productivity.
Unfortunately, this creates more inventory of work for others to process. For example, there are always more developers than QA staff in organizations that I’ve dealt with, so consider the inventory that will pile up on QA if all the developers cranked out code all of the time. And before we consider this to be a good problem, how much of that work would be of high quality and truly valued by the customer? And how much would need to be changed because once the customer saw the code, they decided that they didn’t like it? This creates waste that one of the principles of lean wants us to eliminate. And there is another problem: because of the QA constraint, we would encounter a long delay before we got that customer feedback. This delays learning about what the customer truly needs.
This is why agile shifts the focus to the team producing a customer outcome, with less emphasis on intermediate outputs. That’s not to say that we ignore those intermediate outputs, because we don’t. As one of the principles in the Agile Manifesto states, agile development expects good design and technical excellence. But we need to deliver small features rapidly in order to aggressively manage the ROI of each product. Each small feature represents an opportunity to make economic decisions that impact the ROI.

Q7: So another quality of the organization is “seeing the whole” and focusing on delivering value to the customer first and foremost, correct?

A7: Exactly.

Q8: What else should today’s functional managers be doing differently? What qualities should they posses?

A8: I really like how Mike Rother put it in his book, The Toyota Kata. Mike talks about how Toyota’s managers don’t focus exclusively on improvement; they concentrate on increasing the improvement capability of their people. In learning organizations that use rapid, frequent delivery cycles managers must spend more time developing their people or assisting in the development of their people so that learning is timely.
Another way to help to people and teams is with the qualities of transparency and visibility. With agile adoptions transparency and visibility are typically viewed as transparency and visibility into what the development team is doing, but two-way transparency can be an advantage.
For example, understanding key business metrics such as profitability per customer, product profitability, etc. can help build commitment and a sense of urgency along with keeping employees more aligned with the strategic initiatives because they are more informed about the business.