Coaching the Agile Architect – Creating Value, Ensuring Quality, and Empowering Change

Last Updated on Tuesday, 22 April 2014 08:44 Written by Michael Robillard Tuesday, 22 April 2014 08:44

Coaching the Agile Architect

As an Agile Coach, I typically find two shifts in perspective helpful for new agile architects: first, the possibility of delivering slices of functionality (typically prioritized by risk or value) and second, the possibility of delivering slices of architecture required to support incremental delivery.

I experienced this perspective change personally in what now feels like a previous life as an architect who was expected to construct solutions in addition to architecting them. As a result, I thought it might be most appropriate to discuss how an agile coach might approach the second shift in the spirit of the art of the possible while at the same time trying to keep it simple.

My goal is to incrementally and iteratively formulate a framework to help coach a new agile architect through the required transition of thought in designing architectures that enable incremental delivery of value. While it does not require BUFD, it does require thoughtful consideration of architectural requirements such as quality attributes, NFRs, and expected points of volatility and extensibility. As will eventually become evident, the details contain gotchas that are easily avoided with due consideration.

Two Potential Perspectives

The way my mind works, there are two obvious representations of the context.

In the first, I view an architecture using the following entities:

• Things – which commonly talk to other things using…
• Messages – which contain or, in some way, transmit…
• Information – for context, configuration or other processing

A second, and maybe more useful, perspective is to view the architecture in more traditional layers:

• Domain – the public face, internal or external, of architectural value delivery, typically in the form of services
• Capability – the functional or component building blocks
• Interaction – the integration of the capabilities that reside both in and on the architecture

While both perspectives resonate with me, for this discussion I will use the latter. In future posts I will delve in more depth, which will more naturally align with the former.

What are the challenges?

So what are the challenges I commonly face in this particular area as an agile coach? The following are common questions that arise:

1. How to support domain service stability during incremental refinement?
2. How to incrementally increase the complexity of integration points while maintaining robustness and managing volatility?
3. How to support component stability while incrementally increasing capabilities?

In addition, each case typically comes with requirements to ensure extensibility and backward-compatibility, as well as the realization of quality attributes such as scalability and performance.

Recognize & Address Each Type of Challenge

As a result, any systematic approach that a new agile architect will find useful must address at least each of these types of challenges.

So I’d like to propose one way to look at this challenge and help your customers complete this mental transition. A particular benefit of this approach is that all the referenced content already exists, is in use, and has extensive information available in both books and the public domain. See the References and Further Reading section at the end.

So let’s dig into each challenge with a bit more detail.

How to support domain service stability?

I suggest approaching this challenge with a discussion of Service Oriented Architecture patterns. The primary benefit of these patterns is to manage the dynamic and volatile service contexts and contracts encountered as the architecture is extended in increments. More detailed information for each of these can be found at soapatterns.org (see references at the end).

Some useful patterns to leverage in this way include:

• Service Façade supports dynamic service contracts by decoupling the core domain capability from the public contract.  This will allow either the core domain capability or the public contract to evolve independently.
• Agnostic Capability helps derive new service contexts by making available well-defined yet common domain capabilities as granular services.
• Protocol Bridging supports protocol volatility by ensuring differences in communication protocols – either type of variant – are handled adequately based on expected protocol volatility, planned or emergent.
• Compatible Change / Concurrent Contracts generally support ongoing modifications by introducing new capabilities without impacting existing ones, and by creating multiple contracts of the same domain capability for specific consumer types.

How to support incrementally built integration?

For integration that will be changing through incremental architecture development, introduce the Enterprise Integration Patterns body of work (Hohpe). The primary benefit of these patterns is to stabilize points of integration from Day 1 as they increase in capability and complexity.

Some common refinement patterns to identify and plan for include the following, which I have personally experienced on several large-scale projects:

• Basic Integration Refinement occurs as a simple integration becomes more complex and capable. An example evolution of integration may include transitions from hard-coding, to file sharing to shared memory to RPC, and finally to messaging. Using other protective patterns, this refinement can evolve with minimal impact to the solution and customers.
• Message Channel Refinement involves the paths of integration becoming more powerful and robust.  For example, message channels may transform from Point-to-Point to Message Bus to the use of Message Bridging. This would use the EIPs called Point-to-Point Channel, Message Bus, and Messaging Bridge. (Hohpe).
• Message Routing Refinement occurs as the routing mechanisms used to put messages on channels move from relatively dumb to elegant and smart. Some examples I have used to incrementally build out a robust routing infrastructure include content-based routing, message filtering, Recipients List, Splitter & Aggregator, Composed Message Processor and Message Broker. While the core integration may have also required change, it was minimal compared to the message routing capabilities protected by architectural design patterns.

How to design capabilities robust enough for incremental development?

This is probably where most technicians are the most familiar, yet it is worth discussing within your coaching conversation as this not only ties the other pieces together but also provides more tools which can be applied at all levels. Here we consider GoF Patterns at the capability level.

Some common design patterns that bring great value to incremental delivery include the following from Design Patterns:

• Factory Method to abstract and extend creation functions. Through a creation interface and inheritance, the implementation determines which class to instantiate.  In addition, more simple factory patterns that do not rely on inheritance may also be applicable here.
• Adapter, Bridge, Decorator, Façade, and Proxy to protect and stabilize structure. Each of these leverages abstraction to stabilize areas where the structure is or may end up being volatile. In most cases, if the extent of true volatility is less than expected, the cost expended for protection will have been minimal.
• Strategy, Command, Mediator, and Template Method for incremental extension of behaviors. Again, through the power of abstraction, component capabilities and behaviors can be extended as needed with minimal impact to the core solution.

Summary

My goal is to create a systematic approach to engage and coach new agile architects in the art of the possible when it comes to architectural slicing. Using generally available and proven patterns at each critical layer of an architecture: the domain, the capability, and the integration, architectures can be designed, communicated, and built in vertical slices which meet quality attributes and stability using an incremental delivery approach. As a coach, communicating this possibility and providing the tools to new agile architects is critical to empower early and often creation and delivery of value.

What do you think?

• What other patterns have you found useful for slicing architecture?
• How have you communicated this technical challenge to new agile architects?
• Would such a system be of use to agile coaches in the technical realm?

The posts that will follow this will go into greater detail to describe my coaching perspectives on the:

• benefits of specific patterns to slicing,
• gotchas to consider,
• concrete examples from enterprise projects and
• steps for using these tools which form their own pattern of analysis

…. all in the hopes to spark some thoughtful discourse and provide coaches with additional tools in the technical realm.

References and Additional Reading

• “Design Patterns.” Wikipedia. Wikimedia Foundation, 14 Apr. 2014. Web. Apr. 2014. http://en.wikipedia.org/wiki/Design_Patterns
• Hohpe, Gregor. “Patterns and Best Practices for Enterprise Integration.” Home. N.p., n.d. Web. Apr. 2014. http://www.eaipatterns.com/
• “SOAPatterns.org.” SOAPatterns.org. www.arcitura.com, n.d. Web. Apr. 2014. http://www.soapatterns.org
• http://www.amazon.com/Lean-Architecture-Agile-Software-Development/dp/0470684208/ref=sr_1_1?s=books&ie=UTF8&qid=1397522531&sr=1-1&keywords=lean+architecture+for+agile+software+development
• For additional reading on agile architecture check out a previous post by Mike Cottemeyer > Scrum Gathering Agile Architecture Talk

Managing the Impossible with an Agile Budget

Last Updated on Tuesday, 1 April 2014 08:13 Written by Isaac Hogue Tuesday, 1 April 2014 08:13

The Agile Budget

Release planning is without a doubt one of the most challenging responsibilities for agile teams… at least that’s what I’ve experienced both personally and while coaching enterprises through transformations.

Most teams are working to deliver solutions where the question of “what will I get” at the end of a release can not be left open ended. Furthermore, these teams don’t have an unlimited capacity. They are working within what appears to be a constrained iron triangle, cost, time and scope are all fixed. Mike Cottmeyer’s recent blog about the agile home builder, discusses this challenge from the perspective of establishing a categorized budget.

It is an approach that I’ve seen work on several occasions.  The process is pretty straight forward, not easy… but also not complex

Here’s a script that I like to use to help move teams from “this is impossible” to, “hey I think we can deliver!”

Getting Started

Before determining how much of the budget should be spent on features, its important for the team to understand the goal of the eventual release.  To help with this, I usually encourage the team to form of a mock press release, announcing their successful release to the world.  Typically this includes key areas or attributes of the release that have made the release impactful to the reader. These are now key success areas for the release

Establishing your Budget Categories

Each of these key success areas start to emerge as high-level categories within the context of a releases budget that can be used to help focus initial scope conversations. From here the key stakeholders can allocate their budget across each of the category areas.

Quick sidebar, the asset that is available for budgeting is usually the delivery system’s planning velocity.

Keep your Eye On the Ball (successful release, budget available)

Now that budget categories are set, the teams need to start working through their release plans and refining their needs for the “right” implementation based on the budget available.  There are many methods for going about this process; but, by far my goto method starts with high-level acceptance criteria for each category, or feature area, that can be clarified through a mix of example user journeys or system interactions. The funds available to each of the categories should be brought down and further applied to each of these so that the planning team remembers to keep its eye on the ball.  A successful release will need to both (1) deliver the functionality needed, and (2) live within the budget that is available.

This is key, without a focus on the budget available (cost) most teams will struggle to limit the scope of a release until its too late. Early budget constraints help to drive out scope that is not critical to the success of a release.

What do you think, what are your favorite ways to vary scope to successfully deliver on previous market commitments?  For more on this topic, take a look at an earlier blog about calculating the budget, in cost, for agile teams.

Redefining Heroics

Last Updated on Wednesday, 26 March 2014 09:36 Written by Tim Wise Tuesday, 18 March 2014 10:25

Recently, while working with one of our customers the topic of heroics came up… okay, this comes up all the time

It seems hard to argue with heroics, from the time we were young we’ve heard stories of heroes in our family tree or national history. The term is attributed with acts of valor and selflessness.

Upon closer examination, frequently we find that the heroics that are being described in many enterprises could be better attributed with undisciplined, or even un-intentional delivery….

How do you define a hero in your business?
How does your business define a hero?
How do you reward the heroes?

A bunch of companies define a hero as someone who swoops into a project to save the day. They work a ton of overtime and get the job done by slaying the vicious dragon. They are capable of quickly stitching up a troubled problem just enough to get it to market.

It’s time for this paradigm to change.

When transitioning to agile there is a high value placed on one of the 12 principles of agile development, the indefinite, sustainable pace. Given the traditional “hero”, we immediately have a conflict. So let’s change the definition of the hero.

Heroics Redefined

• What it is not:
  • working overtime
  • being the goto guy
  • taking over for others
  • saving a project at the last minute
  • the number of bugs you find
  • the total lines of code you write

• What it is:
  • Sharing in successes and failures with the team
  • Practicing commander’s intent by helping the team generate new ideas of how to achieve a goal with an unknown path.
  • Demonstrable selflessness in self promotion
  • Creating a new team option by developing a new Generalist skill
  • Reducing team cycle time

This blog was co-written by Isaac Hogue.

Top 10 Negative Personas of a Daily Standup Meeting

Last Updated on Wednesday, 16 April 2014 02:08 Written by Derek Huether Monday, 17 March 2014 08:49

Agile teams should be holding a daily standup meeting.  Don’t think of it as a daily planning meeting. Think of it as a daily opportunity to have a shared understanding of what is getting done and what lies ahead.  During a daily standup meeting, participants sometimes exhibit negative personas that will detract from the meeting.  As an empowered team, it is your job to self-manage and encourage good behavior. Some of these behaviors are so common, we don’t even realize people are doing them. So, I’m giving them some names. Next time you hold a daily standup, see if anyone exhibits any of these 10 behaviors. If you think of some behaviors  that should be added to the list, I would love to see them.

Daily Standup Meeting Negative Personas

10. Pat Decker the Obsessive Phone Checker

This person does not always pay attention and is constantly look at her (or his) phone. Did a BFF just like something? Did someone on Twitter just favorite that pic of the team board? In addition to checking her phone, she likes to share what she sees with others during the standup. “Pssst, Bob, check out this Vine video or pic on Instagram”. She’s not so loud that she’s overly disruptive but now Bob missed what someone else said during the standup.

9. Stephen Craig who is Always Too Vague 

This person can get stuck on the same task for days but doesn’t want anyone to know. When speaking to the team, they are crazy vague. Stephen will offer very few details until the team pushes for a deadline. He (or she) will use language like “Yesterday I was working on task 123 and today I will be working on it some more”. No other information is volunteered. When asked if they need any help, they clarify they have no blockers or risks.

8. Bobbie Bainer the Team Complainer

When the attention is on Bobbie, get ready for the positive energy to be sucked right out of the room. Bobbie complains, complains, and complains some more. Management, teammates, or the technology is all fare game. Everything and everyone sucks and no one knows just how bad they have it. Don’t bring up religion or politics unless you want Bobbie to go right into a 20 minute tirade.

7. Jess Jewler who loves the Water Cooler

Jess comes to the daily standup to talk, but not about what needs to be done today. Instead, he or she will talk about just about everything else. The next 15 minutes is dedicated to the water cooler. Did you see the last episode of House of Cards or The Walking Dead?  Are you going to watch the Ravens play this weekend?  My son plays Minecraft and constructed this totally awesome building with redstone. Anything is fair game, as long as it’s not about work.

6. Billy Platitude with the Bad Attitude

Billy is a leftover from a bygone era. He was the best of the best mainframe developers and all he needs is a DLD and he’ll give you what you need… in a few months. You want any changes between now and then? Forget it!  He thinks all things agile are stupid and just plays along begrudgingly. You may catch him make cynical “funny” comments at standup to point out how right he is about how stupid agile is.

5. Will Funky the Non-Committal Junkie

Will does not want to be painted into a corner. Typically, he uses language like try, maybe, pretty sure, I’ll get back to you, we’ll see, would like to think, soon, almost. You’ll also see Will be the last person to comment on something and will usually go with the crowd.

4. Tom Mater the Specialty Updater

Tom only gives vague commitments, usually understandable only by those in his discipline. The overall team gains little value from the statements. If you ask him for details, he’ll either tell you to look it up in a tool or he’ll be very technical in his response. Half of the team doesn’t understand what the hell he’s talking about.

3. Drue Gru who thinks he’s Better Than You (and the team)

Drue has been around for a long time. He’s better than you and he knows it.  If you need him, you know where to find him. He either arrives to the standup meeting late or he doesn’t come at all.  He has little to say because you wouldn’t understand what he’s talking about. He already knows everything so what is he to gain by slumming with you and the team for 15 minutes? Let him know when something important happens. *sarcasm*

2. Pearl Revolver the Problem Solver

Pearl means well but she lacks a sense of time. She wants to have in-depth problem solving discussions on obstacles identified during the standup meeting. She’s very curious what issues others are having because she’s going to want to talk it out and fix it right then and there. Even if there is a reserved 15 minutes after the standup, Pearl figures there is no better time than the present to tackle a challenge.

1. Ian Krumpter the Interrupter

Do you listen or do you wait to talk?  Stop and think about that. There is a difference. Ian waits to talk. People can be binary in that way. If you’re talking, you’re less likely to be listening. He wants to prove just how awesome he is so you’ll see him interrupt even if the topic doesn’t really apply to him.

Don’t Sell me Agile, Solve my Problem

Last Updated on Wednesday, 16 April 2014 02:18 Written by Tim Wise Tuesday, 25 February 2014 08:08

A while back I was invited to the AITP Atlanta Chapter for a CIO roundtable discussion that involved questions on agile. The event was a great success and I came away with a bunch of great insights into what topics are on the minds of today’s CIO. One statement that night has really stuck with me.  A wise, retired CIO told me, “Don’t sell me your solution, solve my problem.”

That statement further solidified my belief that I am not “implementing agile” (hang with me), but rather I am solving a problem or a set of problems that commonly occur in enterprise environments.

We don’t sell vials of snake oil. Here’s why that may be the perception.

Let’s consider the state of affairs for a moment. When I get the opportunity to have a discussion with a new organization, the person I am talking to needs me to solve a problem. They might not know anything about agile, scrum, kanban, or any other process. Alternatively, they may have experienced a poor implementation and have an immediate bias to any of the “agile” words (i.e. sprints, daily scrums).

If I am selling them something, I genuinely want to solve the problem, not implement agile. That allows me to be a pragmatic partner with knowledge of agile systems that can benefit my customer. It breaks down zealotry and keeps me honest.

In the end, I am directly and intentionally not talking about agile, scrum, kanban, or lean or anything else that is under the agile umbrella. I simply want to know, what is the most impactful issue that their enterprise is facing right now in their unique context.  Can I solve it?  No, but we (myself and the enterprise) can. It must to be a partnership though to be an effective sustained transformation.

Here’s the catch. Most, but not all, issues will fall into one of several categories.

• Time To ROI
• Predictability
• Quality
• Adaptability
• Economics

Though categorically these problems are recurring across many business enterprises, the underlying causes can be a complex, interwoven gobbledygook of methods, procedures, and people.

That’s why it’s important to listen and offer up expertise when you understand the problems. It’s an engaged dialog that I am targeting to create a shared understanding of their problem so we can work to create a vision of our solution.  I’m not there just to lend an ear.  That’s why I need all this experience stuff.

Speaking of experience, I have found commonality among the solutions for each of the categories listed above.

Let’s take Predictability.  In order to become predictable, most organizations will need to learn how to systematically decrease batch size, reduce WIP at the enterprise and team levels, and stabilize teams. Inherently, this will increase quality and decrease Time To ROI.  To further improve those, I will need to run experiments on their unique context.

How do they begin to get predictable?  That’s what they need help doing. It’s what scaling agility is really all about. Getting more value out of the system to decrease time to ROI and predictably make and meet corporate goals.  Informed, predictable returns on investment.

At my core, I believe a predictable system is one that we can run experiments on and get most other problems solved.  That’s my key to unlocking the shared potential of both parties.