Skip to main content

Tag: Scrum

Combining Agile Methodologies and Business Architecture

Agile methodologies and business architecture may seem to be two conflicting approaches to delivering software initiatives at first glance.

In reality, they are very complimentary. Agile methodologies get you to execute projects at a much higher pace. Business architecture makes sure that you are not forgetting anything important and looks at all impacts of a project. An Agile project can be executed with lower risk and higher odds of success if it is bulletproofed using business architecture at the same time. Two presentations made at various Business Architecture Guild events are eloquent about that subject:

• Business Architecture & Agile Methodologies made by Whynde Kuehn, Alex Randell, Eric Shayne Elliott, Francis Fons, and Jeffrey Wallk among others.

• Experiences Linking Business Architecture with an Agile/Lean Development Method made by John Baker.

Agile Methodologies

The Agile Manifesto , explains very well the philosophy that is behind the various Agile methodologies used in IT departments to develop relevant software rapidly.

Agile methodologies focus more on the following:

  • Individuals and interactions rather than on processes and tools;
  • Working software rather than on comprehensive documentation;
  • Customer collaboration rather than on contract negotiation; and
  • Responding to change rather than on following a plan.

Lambert 1

As shown in Diagram 1 above, Agile methodologies can involve the use of various methods. One of these methods is called the Scrum Software Development Method with roles, workflow, artifacts, and sprint backlog among others. John Backer shows a typical Scrum lightweight project management process in Diagram 2 below.

Lambert 2

Another Agile method often used is called the Iterative and Incremental Development Method as shown in Diagram 3. This method includes in iteration the following steps: planning, requirements assessments, analysis & design, implementation, testing, evaluation.

Lamber 3

Before executing any Agile methodology, making a requirement breakdown is preferable, as shown in Diagram 4 below. Unelaborated stories need to be estimated and roughly drafted. Serious ones should then be regrouped by high-level requirements, which are enumerated and ranked usually based on business strategies and tactics – where business architecture can play an important role.

Lambert 4

As pointed out in Diagram 5, Agile methodologies are not an excuse to stop producing documentation. Agile is not an opportunity to eliminate planning. Neither is Agile open season for uncontrolled changes or continuous growth in a project’s scope. Finally, Agile methodologies are not about blindly following a set of “best” practices that can be changed from project to project. In brief, Agile is not a reason for not building and maintaining your business architecture from one initiative to another. If, while practicing Agile methods, you don’t know the overall destination and communicate it clearly then are you just making things up as you go along, potentially creating a fragmented mess. Hence the necessity of Business Architecture!

Lambert 5


Business Architecture

Business Architecture is all about building capability, value, organization, stakeholder, information, asset, product, strategy and initiative maps and describing the relationships between them that are specific to your business, as shown in Diagram 6 below. Once in place, Agile experts can use their business architecture model to link their requirements and processes to capabilities and values among others to enable full impacts analysis to lower risk and make sure that there are no surprises while delivering a project/initiative/program.

Lambert 6

According to The Open Group , Business Architecture is part of Enterprise Architecture as one of four architecture domains that constitute Enterprise Architecture. Yet, Business Architecture does not need to be as complicated as Enterprise Architecture tools often suggest. These tools use traditional stages of design, build and implementation. Project management best practices work well with this approach, and it is highly comfortable. However, this approach is lengthy, costly and to cap it all by the time you get to implementation the world has moved on. You potentially end up having the wrong solution because your speed to change is so poor. It is, therefore, understandable that Agile purist cannot warm up to the heavy Enterprise Architecture approach.

Business Architecture, in contrast, is much lighter than Enterprise Architecture. Getting setup for the first initiative(s) may take between 2 and 6 months by importing existing data from other systems already in place in an organization, by building the first levels of capabilities, organizations, information and relevant value streams maps and by finally describing relationships between components/elements of your business architecture model that reflect your company’s reality. Once in place, updated at regular intervals and if made available to the IT community and key stakeholders, your business architecture model will have positive and rapid effects for each additional initiative helping business analysts build well-defined user stories and requirements for which Agile methodologies can be used for better and quicker execution.

Blending Agile Methodologies and Business Architecture

As explained at much greater length in this article entitled “Align your Requirements to Corporate Strategies Using Business Architecture,” Agile experts should build their user stories as shown in Diagram 7 below to make sure that all possible impacts are known and taken into account before delivering an initiative. This technique enables to trace the requirement logic from its basic components, like capabilities, stakeholders, value, information and process. This way, the focus is placed on the strategy and origin of the requirements via business architecture, not simply back to a project artifact.

Lambert 7

As pointed out by Whynde Kuehn, Alex Randell, Eric Shayne Elliott, Francis Fons, and Jeffrey Wallk , by knowing the business and having taken the time to articulate its value streams and capability maps, you can now have immediate and reusable impacts in the following:

  • Requirements/Grooming: what areas must we understand for development or process changes,
  • Prioritization: what is important, what capabilities may not yet be in place, and
  • Scrum/Release planning: better understanding of dependencies and groups of stories/requirement(s) that make up a capability.

Like it or not, Agile Methodologies will gain in its outcome if they blend in their process the use of a regularly updated business architecture model that is made easily available to the IT department of an organization.


[1] The Business Architecture & Agile Methodologies made by Whynde Kuehn, Alex Randell, Eric Shayne Elliott, Francis Fons, and Jeffrey Wallk among others on September 17, 2014 at the Business Architecture Guild Workshop Event in Austin TX.

[1] Experiences Linking Business Architecture with an Agile/Lean Development Method made by John Baker, Business Architect at MasterCard on March 13, 2013 at a Business Architecture Guild Innovation Summit event in Washington DC.

[1] The Agile Manifesto is described on this webpage.

[1] The Scrum Software Development Method Wikipedia webpage.

[1] The Iterative and Incremental Development Method Wikipedia webpage.

[1] Top Diagram in the article entitled “Align your Requirements to Corporate Strategies Using Business Architecture” written by Daniel Lambert

[1] From this webpage.

[1] Figure 5 in the article entitled “Align your Requirements to Corporate Strategies Using Business Architecture” written by Daniel Lambert

[1] Page 13 of the Business Architecture & Agile Methodologies made by Whynde Kuehn, Alex Randell, Eric Shayne Elliott, Francis Fons, and Jeffrey Wallk among others on September 17, 2014 at the Business Architecture Guild Workshop Event in Austin TX.

Better Tools 4: Productivity Tools for Process Modelling in Visio

This post provides three efficiency tools for process modelling and design work in Visio. They provide quick resizing and realignment tools for groups of shapes and a way of moving shapes without dragging its connectors as it moves.

It complements three earlier posts:

Tool 1: SmartSize

SmartSize allows you to resize a set of shapes by example  and allows them to be quickly selected and resized later.

Using the Tool

First, select the exemplar shape and adjust its size. Then select the other shapes in the set. Finally, press the SmartSize shortcut key. All of the shapes will now be the same as the first one selected.


In this diagram, Component 2 and Component 3 will be resized to be the same as Component 1


The three components are now resized and have been assigned a group number so that they can be resized as a group later.

Quickly Resizing Later

Select any member of the group and adjust its size. Then press the SmartSize shortcut key. The rest of the set will be selected. Press the shortcut key again and the set is resized to the first one selected.


Resize Component 3 then press the shortcut key. The rest of the group is selected.

Press the shortcut key again and they are now resized.

Whenever a set is resized, each shape is marked internally with a group number. When the shortcut key is used and there is only one shape selected, the tool first selects all the shapes in the same set. When the shortcut key is pressed again the routine carries out the resizing action.


I use this tool whenever I am working in Visio, especially when preparing context diagrams and structural representations. In these diagrams, having consistent shape sizes as the content in each shape is added means regular adjustments. While Visio has some resizing features, they are somewhat hidden and lack the resize by example and group management features seen here.

Learning about Visio

This was the first tool I built in Visio many years ago. It uses many of the shape management concepts that are used for more advanced tools.

The size of a shape is determined by the height and width values that you can see when you view its shapesheet. The tool uses a simple loop to step through the shapes in selection set. It finds the height and width of the first shape and assigns these values to the remaining shapes in the set. The looping, variable handling, and assignment of values to the shapesheet form the basis of most other Visio programming.

Tool 2: SmartAlign

SmartAlign allows you to align a set of shapes by example and allow them to be quickly realigned later.

Using the Tool

Select a shape that has been positioned correctly. Then select the other shapes that should align to it. Then press the SmartSize shortcut key. All the shapes are now aligned through the middle of the first. There is a separate shortcut key for vertical and horizontal alignment.

In this diagram Process 3 has moved and Process 1 and Process 2 have been selected for alignment

Using the shortcut key has realigned the shapes

This diagram shows that a similar shortcut key can be used for vertical alignment.  

Quickly Realigning Later

Select any member of the alignment set and move it to its new location. Then press the shortcut key to reselect the rest of the alignment set. Then press the shortcut key again. The set now aligns with the first shape selected.

Whenever a set is aligned, each shape is marked internally with a group number. When the shortcut key is used and there is only one shape selected, the tool selects all the shapes in the same set. When the shortcut key is used again, the routine carries out the alignment action.


I use this tool whenever I am working in Visio, especially when process modelling and preparing framework and structural diagrams. The ability to quickly align and realign the same set of shapes can save a lot of time, especially as the model matures and the layout adapts. The Visio tools for alignment have improved over time, and work reasonably when initially laying out a model. They are not so great for making quick changes later.

Extending SmartAlign: Automatically Selecting Shapes

SmartAlign has an extension which allows you to automatically select shapes to align. This can be used when aligning shapes for the first time, or when you have a group of shapes and want to extend it to include additional items in the same band running across or down the page.

The first time you press the extension shortcut key, the routine selects those shapes that are most closely aligned the first shape selected. Pressing it again widens the selection to include an increasingly broader set of shapes. The fourth press returns you the start point if there are shapes selected that were not intended. There is a separate extension shortcut key for both horizontal and vertical alignment.

Learning about Visio

SmartAlign extends the concepts developed in SmartSize. It shares the looping concepts but adds the ability to programmatically call the Visio functions like alignment that are seen in the UI. A quick way of getting started is to use the macro recorder and then inspect the code that Visio generates itself. Another key feature this routine highlights is the ability to create and manage the content of custom property fields. These fields are used to store the identifiers that define sets used in SmartSize and SmartAlign. When a new group is identified, the internal GUID for first shape in the set is assigned to the property value in each of the others. If the property does not exist, it is created. Later, a routine in the code selects those shapes which have the same attribute as the one selected.  

Tool 3: Break Links

Break Links removes the connections to a shape so that it can be moved without dragging the connectors with it. The end points of the connectors remain in their current location so that another shape can be dropped in its place. Usually, Visio will then automatically link the connectors to the new shape.

In this diagram, Process 4 has been selected, the Smart Tool Menu shortcut key pressed to show the menu and Break Links selected

Process 4 has been moved away and Process 5 can be inserted and the connectors linked to it automatically.


I use this tool regularly, especially in the early phases of process modelling when the structure is fluid and changes are frequent. I often need to move a process shape sideways to make room for another. Dragging the shape drags its connectors too, and this can be a pain, so it can be easier to break the connectors before the move.

Learning about Visio

This routine illustrates some key features of one dimensional shapes (connectors). When unconnected to a shape, the start and end coordinates point of a connector are expressed as (x,y) positions, however when connected, these end point s refer to locations on the shape it is connected to (its parent). To break the links, the routine determines the parent location as (x,y) coordinates and assigns these to the end points. This means the connector loses is parent link, but its endpoint remains in the same place.

Is Agile a Cult?

Agile: a set of software development principles in which requirements and solutions evolve through collaboration between self-organizing, cross-functional teams.

Agile software development is insanely popular at the moment. It offers a responsive way of developing, and companies are adopting it at a rapid rate.

I’m not going to talk about the benefits of Agile – a simple Google search will tell you more than you need to know.

What I do want to touch upon is a comment that someone made to me – “Agile is too much like a cult“.

So, let’s have a look.  Is Agile a cult?

Definition of a cult

  1. A small religious group that is not part of a larger and more accepted religion and that has beliefs regarded by many people as extreme or dangerous.
  2. A situation in which people admire and care about something or someone very much or too much.
  3. A small group of very devoted supporters or fans.

– Mirriam-Webster

Which applies?

Looking at the above definition, it is obvious that Agile does not fit into the first explanation. What about the second one? (Or the third?)

The Cult Checklist

Michael D. Langone, Ph.D. published an article in which he describes patterns found in cultic environments. Let’s see how Agile measures up.

The group displays excessively zealous and unquestioning commitment to its leader and (whether he is alive or dead) regards his belief system, ideology, and practices as the Truth, as law.

I’ve got to admit that I have met lots of Agilist that are of the opinion that anything non-Agile (aka Waterfall) is inferior and wrong. In fact, any discussion on “Agile vs. Waterfall” can turn quite heated with those supporting Agile to be very  passionate about the “truth”.

Questioning, doubt, and dissent are discouraged or even punished.

Refer to my comments above.

Mind-altering practices (such as meditation, chanting, speaking in tongues, denunciation sessions, and debilitating work routines) are used in excess and serve to suppress doubts about the group and its leader(s).

I haven’t seen any evidence of this. (Unless you can consider the “weekend Hackathons” that are often held by ‘self-organising teams,’ as a debilitating work routine.)

The leadership dictates, sometimes in great detail, how members should think, act, and feel (for example, members must get permission to date, change jobs, marry—or leaders prescribe what types of clothes to wear, where to live, whether or not to have children, how to discipline children, and so forth).

Nope … 

The group is elitist, claiming a special, exalted status for itself, its leader(s) and members (for example, the leader is considered the Messiah, a special being, an avatar—or the group and/or the leader is on a special mission to save humanity).

Well, I have detected a certain “elitist” tone when Agile supporters talk about their passion. I’ve even heard someone say “We are Agilist – we don’t believe in …”. How well this fits the description?  You decide.

The group has a polarized us-versus-them mentality, which may cause conflict with the wider society.

Definitely a polarized us-versus-them mentality. Primarily when discussing non-Agile development methodologies but, to the best of my knowledge, this does not cause conflict with the wider society.

The leader is not accountable to any authorities (unlike, for example, teachers, military commanders or ministers, priests, monks, and rabbis of mainstream religious denominations).

It is true, however, not even relevant.

Related Article: 5 Lessons From Working With Agile and Waterfall Teams

The group teaches or implies that its supposedly exalted ends justify whatever means it deems necessary. This may result in members’ participating in behaviors or activities they would have considered reprehensible or unethical before joining the group (for example, lying to family or friends, or collecting money for bogus charities).

I burst into laughter when I thought how Agile could fit this description …

The leadership induces feelings of shame and/or guilt in order to influence and/or control members. Often, this is done through peer pressure and subtle forms of persuasion.

Laughter again….

Subservience to the leader or group requires members to cut ties with family and friends, and radically alter the personal goals and activities they had before joining the group.

Nope …

The group is preoccupied with bringing in new members.

Not really.

The group is preoccupied with making money.

Aren’t we all?

Members are expected to devote inordinate amounts of time to the group and group-related activities.

See my comments above on Hackathons.

Members are encouraged or required to live and/or socialize only with other group members.

If this is happening, I feel that I have missed out. No one every encouraged me to live or socialize with other group members.

The most loyal members (the “true believers”) feel there can be no life outside the context of the group. They believe there is no other way to be, and often fear reprisals to themselves or others if they leave (or even consider leaving) the group.

Well, I know that the Agile “true believers” are unwilling to consider anything that is non-Agile. To even mention the phrase “fully documented requirements up front” would result in feeling the true wrath of the Agilist. (Note – this is not something that I am even recommending. It can be dangerous). However, most Agile supporters that I have met do not fit this description. (There is no fear of reprisals.) 

So – is Agile a cult?

Yes and no.

Looking at the Mirriam-Webster definition, Agile is something that people admire and care about very much (or too much). True Agilists are very passionate about the Agile methodology and often have disdain for anything that isn’t Agile. You see more Agile “groups” than with Waterfall (for example). And there seems to be a need to identify with each other, and promote Agile to both “non-believers’, and well as to those who already are followers.

However, Agile certainly does not have all the characteristics that Langone describes in his essay. There is no “mind control”, or strict, unquestionable, rules.

All-in-all, I think we can all sleep safely in the knowledge that our children are not going to be dragged off to some Agile compound somewhere.

Do those promoting Agile seem a little over-enthusiastic (albeit zealous)? Or is it just healthy passion for something that is a good idea? Leave a comment below.

Strategy Spotlight: 9 Steps to Take You From Strategic Plan to Implementation

Creating an Execution/Implementation Culture is all about getting things done through people. To do that, you need to get your senior team on the same page in their thinking about management vs. leadership and how it relates to empowering people to get things done.

One of the ways to do this is to work through the process from strategic planning to tactical implementation. As part of your planning process, consider these nine key items to get your senior management team rowing in the same direction.

1. Define Strategy

If you have strategic items that the senior team must deliver, review them. Get them down to 3 to 5 strategic agenda items and into words that can be remembered by you and your people.

2. Set Initiatives

Start the process of defining your key initiatives that relate to the strategic agenda items. Depending on the size of the organization, these may be referred to as enterprise or program items. No matter which term you use, create strategic initiatives that serve as umbrellas for actual project work.

3. Establish Elements

Establish the big chunks of work that must be done. Work statements should always start with a verb and be action-charged. These are the key elements and are referred to as statements of work. They are not tasks. You should only have 3 to 5 key elements at the end of this step.

4. Create Measurable Outcomes

To create measurable outcomes, use the SMART (specific, measurable, attainable, realistic, time-bound) or CAR (challenge, action, result expected) models. When writing measurable outcome statements, make sure they are no more than three sentences. The longer and more detailed the information the greater chance you will lose your key stakeholders.

Related Article: 7 Steps to Kick-Start Your Strategic Planning Process

5. Enable Champions

Every initiative should have a champion. Champions are leaders who use vision and influence to get things done through people. A Champion is not the same as being a manager. Managers are operational and get things done through authority. It is important that Champion be empowered to work across the organization and functional lines to lead and support the strategic initiatives, required outcomes and work elements to ensure success.

6. Agree on Timelines

All initiatives should have timelines. There should be an overall timeline for each strategic initiative and separate timelines for work elements. Discuss and agree upon timelines. Not everything has to happen at once.

7. Assign Leaders

Work gets done by leveraging resources. In this case, the resources are defined as people. At this level, the Initiative Champion seeks Project Leaders within the functional business areas to rise and take responsibility for organizing people to get the chunks of work completed. The project leaders must break down the chunks of work, gathering additional resources and creating micro-timelines to meet key milestones.

8. Forecast Costs

The Initiative Champions working with Operational Managers and Project Leaders should work together to define the true costs associated with the strategic initiatives and the associated work. Some initiatives will be operational, and others will be clear projects.

9. Establish Alignment

There should always be an alignment stream associated with your strategic initiatives. The alignment stream should include objectives for creating a common language for communications, establishing awareness and activation abilities, and building collaboration skills.

Not everything happens at once. The senior team will make mistakes. They may become overwhelmed with what needs to be done. Maybe timelines aren’t fully discussed and agreed upon. An execution culture is cross-functional and self-directed. It’s not a clear-cut process. People need a path to follow. As the senior team, give them one.

Question: In what way are you engaging others in your strategic and tactical planning efforts to ensure you achieve successful implementation?

Leadership Lessons: Implementing Change – A 7 Phase Methodology – Phase 1

Editor’s note: We will be showcasing each phase of Peter de Jager’s methodology in weekly posts. Check back every week to read the next phase.

How should we implement change? It’s a simple enough question, surely there’s a simple answer — especially since we get to do it so often. Every time we implement a new system or install a new process, we’re implementing change. Surely there are some things that work, and some things that fail? Surely we’re intelligent enough to sift out the good from the bad? Perhaps.

We have a problem. We need to understand the deep mystical secrets of change implementation.

We know some of these secrets involve the target audience;

  • Making it their change, not your change; providing support during transition;
  • Celebrating small successes etc

Sounds like motherhood and apple pie. Perhaps that’s why we ignore them so often. But Robert Fulghum was very successful with a simple little book entitled ‘All I really need to know, I learned in kindergarten’. Perhaps we need to follow his advice and pay attention to the obvious and the simple.

Perhaps when it comes to Change, all we really need do is paraphrase Fulghum and state “All I really need to know about Change, I learned in my last failed implementation!” and add this commentary as a warning… “I ignore them at my own peril!”

When faced with Change, any Change, our immediate response is “How will it affect me?” Will it destroy a way of life, or just disrupt a sense of comfort? Will it threaten jobs, or will it just be perceived as threatening jobs? Does it matter if it is a perception rather than reality?

Everyone shares these simple, personal, self-preserving questions. Answer them and you’ve solved the problem of implementing Change. Ignore them and you guarantee yourself a difficult, if not impossible, transformation.

Related Article: Leadership Lessons: Change in Seven Questions

There are no silver bullets in change management. No guaranteed, money back solutions. Your change strategy will depend on the present situation, your history, the future you’re trying to create and how difficult you make the journey from here to there.

The bottom line is, there is nothing you can say to someone you’re about to layoff that will make them feel better. If you’re looking for such a solution, then you‘re looking for the Holy Grail, it doesn’t exist.

On the other hand, if you’re trying to get a target audience to accept a new way of doing things, a new system or a new set of standards, then there are partial solutions. Solutions that allow the target audience to gain some control over their destiny while implementing the necessary changes.

The following list of questions and suggestions are intended to entice you to think about the whole situation, past and present, not just the uncertain future you’re trying to build.

Phase I: Understand the Change

Before we implement change, it’s imperative we understand all the reasons for it. We must become experts in the change being proposed or reacted to, because people will look to us for answers. They might even look to us for guidance. At the very least “Is the change necessary?” will be asked by everyone impacted by it. It would be nice to have an answer.

  • What/Who is the Foreign Element?

The foreign element is the event, or person, which will disrupt the ‘way things were” otherwise known as the status quo. It’s dangerous to assume that the ‘foreign element’ is obvious to everyone. If the foreign element is misidentified, then the change will be more difficult to manage. This is sometimes another way of asking “What’s the real agenda?” If assumptions are made about why this change is being made, and these assumptions are wrong, it is likely the type of change implemented will not address either the real issue or that hidden reason for the change.

  • What happens if we don’t change?

What are the consequences if nothing changes? How certain are we that these consequences will take place? If the target audience does not believe the consequences will occur, or if the consequences have no noticeable positive or negative impact on them, they will not be motivated to move forward. People need to understand the real necessity for the change. Most people, when they understand the need to change is real, are unlikely, for reasons of self-preservation, to resist the change as strongly as those who believe the change is unnecessary.

  • Who is affected by the change?

Closely tied to the question of consequences. Will *I* be affected? If I’m not affected? Why should I change? It’s possible, and it happens often, that one way to reject change is to live under the belief that it doesn’t affect me personally. Identifying the ‘target audience’ is crucial to any change project.

  • When will the change take place?

The more imminent the change, the more people can relate and respond to it. Sometimes the only way to get people to accept that a change is ‘real’ is to attach a firm date for implementation. We’re all busy, our plates are filled with projects and important to-do items. If a change doesn’t have a deadline, if a priority has not been assigned, if budgets are nonexistent, then the change itself doesn’t really exist and it will be ignored. Distant change is less ‘real’ than imminent change.

  • Why now?

What forces this change upon us at this point in time. Why not next year? Why not last year? What makes it important that we act now? What is it about this foreign element that causes it to affect us today? If this change was really important, why didn’t we address it sooner? All of these questions, if answered properly, provide justification for the change. They legitimize it. If the answers aren’t readily available, you’re communicating to the target audience that this change is arbitrary.

  • How will the change affect us? Today? Tomorrow? In the long run?

This is another key question. Another version is “What’s in it for me?”

© 2015 Peter de Jager – Reprinted with Permission