Disciplined Agile

On May 17 2016 I gave a webinar entitled Agile Enterprise Architecture: Disciplined and Pragmatic Strategies (at this link you can watch a recording and download a PDF of the slides). During the webinar I received many questions, some of which we had time to answer but some which we did not.  Regardless, here are all of the questions and my answers.  I’ve organized them into the following topics:

1. Long vs. Short Term
2. Deferring Commitment
3. Transitioning to Agile EA
4. General

1. Long vs. Short Term

What about longer term? How do you see the role of EA on portfolio creation?  As you can see in Disciplined Agile’s Enterprise Architecture process blade one of the primary tasks of the EA activity is to consider the longer term. The enterprise architects will collaborate to do so, and will help bring their vision to their stakeholders in various ways.  As you can see in the workflow, the EAs will interact with the Portfolio Management effort (and many others).

How do you balance the needs of today vs. the needs of tomorrow? Would you wait for business to identify it as a priority, which may be too late… or look to get ahead of the curve and build something that can scale for anticipated growth? Experienced enterprise architects will definitely think about the long term needs of the organization. Disciplined Agile EAs will do so but will wait to act to the most appropriate time to do so.

2. Deferring Commitment

Can you point us to some places to read more about deferred commit? Deferring commitment to the last most responsible moment is a concept that comes from lean software development. I recommend the writings of Mary and Tom Poppendieck as well as the book SDLC 3 by Mark Kennaley.

If we defer commitment, how about if we need infrastructure, procurement and so on to implement that architecture? This deferring will delay the entire implementation? No. The advice is to defer commitment to the last most responsible moment.  You need to understand the needs of your stakeholders, which in Disciplined Agile include a wide range of people, and then act accordingly. The problem is that traditionalists will act too early and thus add unnecessary risk.

A good observation from Valentin Tudor-Mocanu is that to be able to defer decisions we need a design that separates the concerns (adaptive design).

3. Transitioning to Agile EA

Is there a strategy to change the mindset of enterprise architects on a large organization?  Yes. It first begins with education.  We offer a one-day workshop called Agile Enterprise Architecture: Disciplined and Pragmatic Strategies that does a very good job of working through the fundamentals.  The next step is coaching of the EA team themselves, and of the teams that they interact with, to help them gain the mindset and habits required to work in a more effective agile/lean manner.  We also provide such coaching services.

One specific question related to a service or consulting organization: One of the specific requirements for us to is to deliver architecture as a deliverable. How can agile can help us?  Can we apply sprints there?  Can we apply any architecture principles? I’ll assume you meant an architecture model as a deliverable. The answer is yes, you can easily create an architecture model in an agile manner. I highly suggest that you visit the Agile Modeling site and read the advice about agile architecture strategies and to agile documentation strategies.

4. General

Can you talk about metrics in agile EA and Architecture in general?  In the Disciplined Agile (DA) toolkit we suggest that you adopt a lightweight Goal-Question-Metric (GQM) approach to your metrics strategy. The fundamental idea behind GQM is that you first identify a goal that you would like to achieve, a set of questions whose answers are pertinent to determining how well you’re achieving that goal, and then the metric(s) that could help you to answer each question. In short, the metrics that you gather will vary based on your need.

Given that Feedback cycle plays an important role, why does DAD say “Reduce feedback cycle”? Is there a pre-defined cycle frequency?  You should find the blog posting Reducing the feedback cycle requires discipline to be an interesting read.

Some forms of architecture (UX/UI) need a different cadence than the delivery team follows. What is your recommendation for handling this… UX research, etc? I disagree with your premise. I’ve heard this claim in the past and it’s never held water with me.  About 10 years ago I wrote an article entitled Introduction to Agile Usability that overviews how UX activities can appear in the agile lifecycle.  The Lean UX community has clearly gone further than what I originally wrote so you might want to go poking around on the web a bit.

When the business case says “many years before payback”, doesn’t that usually mean that the business case is missing some important elements? (or that the org is really small) ?  My experience is that the business case is usually crap in these situations. There in fact a few things in the software world that may have a multi-year payback period, operating systems come to mind, but they are more the exception to the rule.  The problem with multi-year payback schemes in the software world is that the ecosystem changes so quickly.  During the several years it takes for payback your needs change, there are new options on the market, your organization structure and direction may change, and so on.

I realize I’m asking a history question here, but regarding deferring commitment, a superb method for this that I have often used in the past comes from RUP: architecture mechanisms. (I should know this but) Is this in DAD?  If you read the Enterprise Architecture process blade article you will see that it supports several strategies for capturing and communicating EA ideas such as reference architectures, models, architectural runways, interfaces, and many others. You might also find the Reuse Engineering process blade to be of interest.

Governance is a common thread throughout all aspects of the Disciplined Agile (DA) tool kit. Delivery governance activities were built right into Disciplined Agile Delivery (DAD) v1.x, each of the process blades include a governance process factor, and there is an IT Governance process blade that coordinates all IT governance activities.

The following process goal diagram overviews the potential activities associated with a disciplined approach to IT governance.  These activities are typically performed by a variety of people within your organization. In DA each of the process blades includes activities around governing the activities encapsulated by that blade. For example, the Enterprise Architecture blade includes architectural governance activities and the Data Management blade includes data/information governance activities.

The process factors that you need to consider for IT governance are:

1. Governance view. There are many potential aspects, or perhaps subsets, to IT governance including security governance, data governance, delivery governance, and more. Too many organizations make the mistake of treating each of these issues separately, which is easy enough to do given the different focus of each one. The Disciplined Agile toolkit promotes a more holistic, integrated view that results in a streamlined, consistent, and effective governance strategy. Another common mistake is to focus on portfolio governance over other aspects and have your Portfolio and Project Management Office (PPMO) be responsible for IT governance. PPMO-led governance efforts tend to result in documentation-heavy, bureaucratic strategies instead of lean, risk-based approaches.
2. Develop metrics. Metrics define the measurements that you will take to gain insight into what has happened, what is happening, and hopefully what may happen in the future. The least effective approach to metrics is to have a standard set that all teams are expected to collect whereas the most effective is a context-sensitive approach such as a light-weight implementation of Goal Question Metric (GQM).
3. Measure. The measures themselves can be collected either manually or automatically (usually as the result of tool or system usage). We have found that a combination of the two is required – although automated metrics are inexpensive, accurate, and real-time you cannot always automate all of the measurements that you need to collect.
4. Monitor. Information radiators are sufficient in smaller organizations, but automated dashboards in combination with direct interaction with teams are also needed in modern enterprises. Traditional strategies, such as status reports or status meetings, do not prove to be effective in practice nor do they provide an honest assessment of what is actually occurring.
5. Guidance detail. An easy and important way to support governance within your organization is to have commonly accepted guidance, including standards and guidelines, for teams to follow. We suggest that you keep this guidance lightweight, starting with high-level rules but aiming towards principles whenever possible.
6. Develop guidance. Guidance is ideally developed collaboratively with a combination of practitioners and experienced enterprise IT professionals who understand the bigger picture.
7. Define roles and responsibilities. The definition of roles and responsibilities is an important aspect of your overall governance strategy as it describes what is expected of people. We’ve found that the most effective way to do this is to start with the roles and responsibilities described in the Disciplined Agile (DA) toolkit and then collaboratively evolve them from there. The framework ha both delivery team roles as well as enterprise IT roles defined.
8. Manage IT risk. Risk management for the entire IT portfolio, including both in-progress development teams as well as operational risks. Small risks on individual teams can add up to a large risk across your organization. For example, if many teams adopt a new and relatively unproven framework and that framework is then abandoned by its creators (think about how many open source projects or new companies flounder) then you have a serious problem. Similarly, when multiple teams start addressing a similar business opportunity and that line of business dries up or is legislated away.  Although risk management is addressed on delivery teams via the goal Address Risk, their focus is on risk management within a team as opposed to risk management across all of IT, or even across all of your organization.

Related Reading:

• The Lean Governance Mindset
• Lean Governance Strategies
• What is Lean IT Governance?
• Why Lean IT Governance?
• What is Agile Delivery Governance?
• Strategies that Enable Agile Governance
• Supporting Agile Delivery Team Governance
• Lean vs. Traditional IT Governance

There are several strategies that you can adopt to promote a lean approach to governance. These strategies include:

1. Empowered teams. Teams should have both the authority and responsibility to fulfill their mission. Agile teams should be allowed to be self organizing, the implication being that the team itself determines who will do what work (the team doesn’t have a manager telling them what to do).   Related to that the team should own their process, which is the agile way of saying that the team is allowed to determine how it will work together and as the team learns it will evolve the process that it follows – of course the team will be guided and constrained by your organization’s governance strategy.
2. Enterprise awareness. One of the principles of the Disciplined Agile (DA) toolkit is that you should work in an enterprise aware manner. It is based on the observation that your team is only one of many teams, so therefore you need to consider the bigger picture when you’re working and do what is best for your organization, not just what is convenient for you. Promoting enterprise awareness throughout your organization is a fundamental enabler of lean governance.
3. High-level roadmaps. High-level technology and business roadmaps, produced by your Enterprise Architecture and Product Management efforts respectively, will provide important guidance to your teams. These roadmaps capture the vision as to where your organization is heading, helping teams to understand what the overall vision is, to focus on what is important to your organization, and to help guide and constrain their decisions.
4. Collaborative enterprise IT professionals. The DA toolkit includes several process blades, including Enterprise Architecture, Reuse Engineering, Data Management, and others that address enterprise level concerns. The people performing these activities should work closely with their customers, the delivery teams and stakeholders, in a collaborative and evolutionary manner. This promotes better governance for two reasons. First, by getting the vision, knowledge, and skills of the enterprise professionals into the hands of their customers it increases the chance that they work in a manner that is consistent to the needs of your organization. Second, the enterprise professionals want to get feedback from their customers and learn more about what their customers need from them. This enables them to be more effective at serving the enterprise and guiding their customers.
5. Enterprise IT knowledge in teams. Although roadmaps and enterprise IT professionals collaborating with development teams help, it is far more effective to have people with enterprise knowledge embedded within the development teams. This is why we promote the idea that Architecture Owners (AOs) should not only work closely with the enterprise architects but should preferably be a member of the EA team. Similarly, Product Owners (POs) should either work closely with the product management team or preferably be a member of that team.   And it’s possible to do better than that – if team members are truly enterprise aware and are continuous learners, then it is reasonable to expect them to pick up enterprise knowledge over time. The more knowledgeable people are about their organization and its goals the less supervision/governance they will need.
6. Automated dashboards. Automated dashboards, a strategy that we’ve referred to as development/operational/IT intelligence in the past, is a scalable form of information radiator. With just a bit of work you can take the information being generated by your tools and, using business intelligence (BI) technologies, populate team and even portfolio dashboards in real time. These dashboards provide important information that teams can use to manage themselves as well as governors to monitor what is happening within your organization. This enhances governance because when you get better quality information into people’s hands and they are more likely make better decisions.
7. Defined roles and responsibilities. Defined roles and responsibilities help people to understand who does what, what are they are responsible for and when they need to collaborate with others. This is an important aspect of governance because critical guidance about how people will need to interact with one another.
8. Defined organizational structure. You may choose to have a hierarchy of teams, a network of teams, a collection of circles (along the lines of holocracy), or combinations thereof. This is important to your governance efforts because people need to know what are the teams and how do they interrelate within your organization.
9. Common guidance. Guidance – standards and guidelines – is important to your governance effort because it helps people to understand how they can develop consistent assets which in turn are easier to understand and evolve. Common development guidance includes coding standards, data naming conventions, user interface (UI) design guidelines, security standards, and more. This guidance should be straightforward, ideally be supported through automation, and collaboratively developed.
10. IT governance team. People, typically senior people, are responsible for IT governance. The team, who is on it and what they do, should be defined and publicly known by those being governed. Everyone knows who the governors are and what they do, so that your governance strategy is open and transparent.

In the next blog posting in this series on governance we’ll overview the process goal diagram for IT governance.

Related Reading:

• The Lean Governance Mindset
• What is Lean IT Governance?
• Why Lean IT Governance?
• What is Agile Delivery Governance?
• Strategies that Enable Agile Governance
• Supporting Agile Delivery Team Governance
• Lean vs. Traditional IT Governance

The mindset required to govern IT in a lean or agile manner is very different than the traditional mindset. In this blog we review the key aspects of a lean governance mindset. These aspects are:

1. Lead by example. People take their cues from their leadership teams. If your governance strategy is streamlined and light weight then whatever it governs will inevitably become streamlined and light weight. Conversely, an onerous and heavy governance strategy will lead to onerous and heavy strategies by those being governed.
2. Be a servant leader. The primary function of governance people should be to prevent roadblocks, and if not to get rid of them as soon as they arise. You should strive to get teams the resources that they need and then get out of the way. Wait a minute, isn’t that the job of the Team Lead in Disciplined Agile (DA)? Yes, but who do you think that they work with to actually get that done?
3. Motivation over management. IT professionals are intellectual workers, and intellectual workers generally don’t respond well to being told what to do. But they can be motivated, and once motivated will actively work on what they’ve been motivated to do. So motivate them to do the “right thing”. One way to do this is to communicate very clearly what your organization is trying to achieve. Another way to motivate people is to ask tough questions such as: What value is there in doing that? What can we do to increase value? How can we eliminate waste in what we’re doing? and What will we learn by doing that?
4. Enablement over audit. Psychology shows that people, when given the choice, will usually take the easy path. This tells us that if we want people to do something, or to work in a given manner, then if we make it very easy to do so then they likely will. For example, if you want developers to follow common coding conventions then provide easy to understand and straightforward guidelines. Better yet, provide code analysis tools that they can include in the continuous integration (CI) tooling that provides feedback that they can act on. The traditional approach would be to rely on code inspections or code audits to ensure that conventions were being followed. This approach is not only onerous, and thus less likely to be followed, it has a long feedback cycle which means that any feedback resulting from the audit will be much more expensive to act on (on average) than the code analysis tool which has a very short feedback cycle. Yes, you may need to run the occasional audit, particularly when you’re working in a regulatory environment, but you should do so only as a last resort.
5. Communicate clearly, honestly, and in a timely manner. Effective governors communicate what the priorities of your organization are and what is expected of people. It is crucial to set realistic expectations in an open, honest, consistent, and continuous manner.
6. Streamline collaboration. Governors should help teams collaborate effectively with others. This not only helps them to achieve their goals but also supports enterprise awareness.
7. Trust but verify. Agile is based on trust, but to ensure that the right thing is happening within your organization there needs to be verification of that. Governors can do this by monitoring teams via several strategies. These strategies include asking people what’s going on, automated metrics (via team dashboards), looking at information captured by information radiators, attending team demos, and as a last resort asking teams to produce status reports to address questions that can’t be answered via automated metrics.
8. Focus on mitigating risk, not just reviewing documents. A primary goal of your governance strategy should be to mitigate risk. Sadly, many governance strategies have fallen into the bureaucratic trap of relying on documentation reviews to provide insight into what a team is doing. For example, your “architecture quality gate” might be based on the review and acceptance of an architecture model or document, the idea being that if some knowledgeable people assess the content of the document they will be able to determine whether the described architecture strategy will work. Unfortunately this isn’t the case. We’re sure you’ve seen several IT project teams who had a well-documented architecture, which was reviewed and signed off on, yet the technologies didn’t work well in practice, or perhaps they didn’t perform well, or perhaps they didn’t even integrate easily. The only thing that the review and acceptance of a document tells you is that a document was created, reviewed, and accepted.
9. Learn continuously. Good governors learn as much as they can about what they’re governing so that they can make better decisions and can make effective suggestions to the people being governed.
10. Consider both the long and short term. Governance must balance short-term needs with the long-term strategy of growing and enhancing your organization.
11. Be a great host. People who have fun at work, who enjoy what they do, are much more productive than people who don’t. In this respect being an effective governor is like being a good host at a party – as host it’s your job to see that everyone has a good time and gets along well with each other, and to swiftly deal with any problems that arise.

Having a lean governance mindset, as described above, helps you to increase your effectiveness at governance. In the next blog we will describe what IT governance encompasses.

On April 19 Disciplined Agile Consortium ran a webinar entitled Disciplined Agile Offshoring: Making it Work for Both the Customer and the Service Provider (follow the link for the recording and other stuff).  During the webinar we received a lot of very good questions, most of which we were able to answer.  We’ve decided to write up the answers to these questions here.   We’ve organized the answers into the following topics:

1. Product Owners
2. Testing
3. Measurement
4. Common Pitfalls
5. Miscellaneous

Product Owners

Ideally, what will be the Product Owner and Team Leader’s location in outsourced agile team? Can a Delivery Manager role be infused?  The Team Lead and Product Owner (or a proxy) should be on site with the development team. Many times, however, the PO is located with key stakeholders who are rarely at the same location as the development team. In this case there will be a need for a proxy, either a business analyst or better yet a (Junior) Product Owner at the site with the team who interacts with the (Chief) Product Owner regularly. You will likely need to apply the Ambassador strategy and have people fly between locations regularly.

Do most successful outsource agile projects have a product owner (junior or otherwise) and team lead role at all sites?  I would suggest that. The team needs someone who can answer questions regularly. The (Chief) PO needs to interact with stakeholders regularly.

Testing

What is included in the scope of the Outsourced Work? Should it include system testing and QA testing?  This depends on what the contract calls for. It is possible to outsource most of the testing effort if you choose to.

What cannot be outsourced apart from UAT/Integration Testing?  Actually, you could probably outsource a lot of your integration testing effort if you choose to do so. User Acceptance Testing (UAT) needs to be done by stakeholders and those people work for the customer organization, not the service provider.

When you’re working for outsourcer, I think it is better to do manual test, to see all bugs before than spend time on automating tests. Is automated test writing always better than manual testing? I think we lose the time on automation.  Automation of yours tests, or I guess more accurately your checks, is absolutely critical to your success. You can’t afford to not automate as much of your testing as possible. Yes, some testing will be manual at first, but once you understand how to run the test manually you should be able to automate it in most instances.

Measurement

What the metrics to evaluate the outsourced agile delivery?  This depends on what your priorities are. Are you trying to improve time to market? Quality? Return on investment (ROI)?   What you measure will be driven by what you’re trying to achieve. We’re a firm believer in an agile approach to GQM.

How to measure the performance of team during outsourced agile delivery?  Once again, it depends. A very good strategy is to include code analysis tools in your continuous integration (CI) strategy that provide the customer with real-time insight into the quality being delivered by the service provider.

Are Development Intelligence (DI) dashboards and code analysis tools something the consumer should expect the Service Provider to have and be using, or is this something that the Consumer needs to acquire and then share with the Service Providers?  It would be incredibly foolish not to use such tools. There are many very good ones available free of charge via open source, as well as some very good commercial tools.

Common Pitfalls

Apart from sending ambassadors, can you suggest any other approaches to eliminate cultural differences and we-they attitude?  The only way to reduce cultural differences is to work closely together.  If you’re not willing to spend at least some money on travel then I would seriously question why you’re doing offshoring at all.

What kind of indicators stand out for failing offshoring activities?  The primary cause of failure of an offshoring effort is an inappropriate procurement process by the customer itself. Other failure factors include an inflexible approach to changing requirements, inadequate monitoring/governance of the project, unwillingness to pay for travel, and unrealistic expectations by the customer.

Miscellaneous

Do you recommend doing development in one place and testing in another?  No. Organizing teams by function injects a lot of overhead, cost, time and risk into your software development efforts. A much better approach is to have a whole team at each location with the skills and resources required to get the job done. Some testing may still need to occur on the customer site of course, but that should be a small part of the overall testing effort.

How can we possibly be called agile when the offshore team is developing while the onshore teams sleep, and vise versa? We fix this with 20 min standups, and heavy process, and using process over comms is by definition, not agile. Should we be happy with water-agile in this case?  You can strive to be as agile as possible in the situation that you find yourself in. As you learned in the webinar there are many strategies that you can apply to become more agile. You might also find our article on Agile GDD to be of interest.

How do you encourage a move away from sign-offs?  There isn’t an easy answer to this one. It is quite common for us to work with organizations to help them to evolve their IT governance strategy to be more agile in nature. We often coach and mentor IT governance people to help them to move away from signing off on artifacts to a more light-weight, risk driven approach. My suggestion is to contact us for help.

Can you share any successful case study in more details?  You can find some fairly easily via a quick web search.