So you thought Agile was simple and easy?

Ever heard that Agile and Scrum are the same thing? Perhaps that was your impression as well? This comprehensive illustration from Lynne Cazaly could possilby help in dispelling that myth:

As you can see from the picture there’s around 40 different agile methods or frameworks. They’re all in the range from simple principles or practices to fully fledged software development frameworks.

….

So called hybrid frameworks has gained attraction in the last couple of years. Among those DAD, SAFe and LeSS are among the best known…..

by Scott Ambler

Architecture is so important on agile teams that we address it continuously throughout the lifecycle.  Interestingly, the most effective solution and enterprise architects are those that work in a collaborative and evolutionary (agile) manner.  In this presentation Scott Ambler works through how architecture practices are addressed continuously throughout Disciplined Agile development and describes pragmatic practices for doing so.  He also overviews how disciplined agile teams work closely with enterprise architects in a light-weight, streamlined manner.  Most importantly, these agile approaches enjoy a greater level of success as compared to traditional ones.

Click HERE to view the presentation

by Alex Randell

Working agile does not provide benefit if we are simply working on the wrong things in an agile manner. If architecture is not considered, we are in peril of not understanding an organization’s strategies, objectives, and value proposition; a problem that can be compounded when agile is scaled, such as with SAFe. This session will demonstrate how practitioners of business architecture can leverage tools such as value streams, capabilities, and strategies in an agile or SAFe environment to amplify the power of both the architecture and the agile practice.

Click HERE to view the presentation

Why an Agile Engagement Model?

Working Page for the Engagement Model Working Group – All Materials are DRAFT.

A very short but basic definition of an engagement model is how we as architects interact and collaborate within an organization. And is there a better way to find inspiration regarding interaction and collaboration between people than in the agile and lean mindsets?

In addition, an engagement model allows architecture activities to be explicitly and directly defined in objective terms using a clear set of guidelines. Given the long standing friction between Agile and Architecture (or at least Big Architecture) this allows the agile organization to explicitly define how architects interact in and out of the SDLC. Organizations which do this are more likely to succeed in both practices.

For instance, as found in two of the Agile Manifesto principles:

#4: Business people and developers must work together daily throughout the project

#6: The most efficient and effective method of conveying information to and within a development
team is face-to-face conversation

And finding the values of strong leadership, clear purpose and employee engagement among the foundation pillars of the “House of Lean” it’s quite clear that the agile and lean mindsets has its place within organizational development. And therefore also its place within an engagement model for IT architects and especially very much aligned with the Human Dynamics foundation pillar of the ITABoK.

How we as architects, with different roles and specializations, find our place within an agile or lean mindset is a different story. On the contrary, architects have been rejected by agile teams (or we have alienated ourselves). For instance, looking back to the Agile Manifesto once again:

#11: The best architectures, requirements, and designs emerge from self-organizing teams

Architecture is great, but no room for architects, right? First of all, we must understand that at the time the Agile Manifesto was created, it was written from a pure software development perspective. And as architects we know that software architecture is only a small part of our profession. But we’ll get back to the potential conflict between agile and lean organizational development and the architect profession further on among the lean and agile engagement pages. First some definitions of what agile and lean really is all about. If your new to agile, or curious about the values and principles behind here’s where to start.

The picture below gives you an idea of a lean and agile adoption of an engagement model. As the core associate engagement model, also the agile adoption takes a middle-out approach on architecting a solution. Capability evolution is an iterative process, so regardless whether you as an architect take a top-down or bottom-up approach on architecting solutions and engaging within the enterprise, you follow the plan, build, run and manage feedback loop, in benefits realization and value creation.

The picture allows you to navigate through descriptions of both agile and architecture artifacts and processes that helps you as an architect to engage in an agile manner:

Note: The “Iterative Lifecycle” and “Capability Evolution” graphics are trademarks of the Agile Business Consortium

I have recently been studying the implications of Agile on enterprise and technology architecture. As a part of that I was looking through traditional architects relationship to other team members (structural engineers, construction, plumbers, electricians, etc). This has always been a passion of mine as a student of professions but this time I was looking at the content of their work instead of role integration (I will have another post on that soon enough). What emerged from this has been in the back of my head for a long time in a very ambiguous sort of way.

It is very clear that the purpose of architects is fundamentally different than those of developers, engineers, project managers, etc and that projects, programs etc that have skilled architects are significantly more successful in terms of outcomes to the business (Value of Architecture). When I speak of outcomes, I am less interested in traditional measures of success such as project schedule, budget and requirements and more outcomes to new revenue, new customers, customer satisfaction, and other business value management outcomes. However, it wasn’t until I was presented with the agile motto, ’emergent architecture’, that I realized the true difference between what Iasa means when it uses the term architect, and the meaning of many others when they use the term.

When we discuss architecture, we are describing it’s Form. When others discuss architecture, they are describing it’s structure. Structure can be emergent. It is my belief that form cannot (or only rarely).

Form

When you think of a building you love, what do you think of? It’s simplicity, complexity, beauty, usage, ability to serve its purpose while fitting into its surroundings? Form in building architecture is the final output. But it is also more than that. It is the value that output creates including the ‘negative space’ which fulfills those things. Negative space is a way of describing that things that aren’t built are as important as things that are. But it is the value that is created that interests me.

In building architecture form can be readily understood at a visceral level. Value is based on elements that most humans can ‘feel’ if not conceptualize. The difference between a good house/apartment layout and a bad one is something most adults have experienced at least once. “Who designed this place, I can’t even put a sofa in the living room!”

In technology architecture it is something a bit more esoteric. Iasa contents that form in technology architecture is the value, satisfaction and outcomes associated with a technology AFTER it is deployed and running. And this form drives and constrains structural decisions for the architect.

Structure

Now think of the same building during construction. That same beautiful and amazing building would not be very inviting to anyone but a building professional, or in my case a 10 year old boy (I grew up in construction and loved it before they were finished). Why is that? It is because until the building is completed it cannot create its intended value for the owner/customer. You likely do not want to live in a house from the beginning of construction.

The structure of the building again is a very visceral feel. The struts, the foundation, the plumbing, the machinery. For people in the building trade it is forever fascinating. In fact, I believe that this is where our notions of architecture in technology have derailed. For structure is the responsibility of both the architect AND the engineer/developer.

Structure is the set of physical and digital components, their interfaces, and the design rationales that control their evolution. It is this that most people think of when talking about architecture. But therein lies the problem we face today. Structure by itself is not valuable to an organization nor is it the soul responsibility of a single professional. Structure CAN be emergent and most often is.

Function

A significant number of programs, projects and products are delivered by function alone. Imagine your building again. Now imagine if they had added just one room at first with no electricity, air conditioning, roof, or other elements. Then the next year they added another room and one light socket. And so forth and so on.

Function in building is roughly equivalent to requirements or user stories in technology driven business initiatives. “Lets setup a Facebook page. Social media!” “We need to be able to calculate the tax on an item in Seattle.” You get the picture. This starts to sound a lot like a truly agile initiative. Focus on the stories that make for a minimum viable product then iterate and transform and adapt. And from a development perspective it is simply heaven. I am NOT bashing agile, nor DevOps, in fact you will find that these definitions make architecture and agile significantly more powerful.

Bringing It Together

Why? Why can’t the team build function and value at the same time? For exactly the same reason that structural engineers, construction workers and building architects are all required to deliver a truly valuable output. Skills, experience, focus. Human limits. The value management (Form) of a product is a fundamentally different set of skills and experience than the construction though they overlap significantly within respective areas. In fact, it takes years to understand the nuance of the impact of technology on a business model while retaining enough technology skill to be relevant and to be able to partner effectively with a delivery team.

But why can’t the product owner understand and manage value delivery? For roughly the same reasons that traditional requirements do not describe an effective outcome in technology and business strategy. Most product owners are decidedly not technical and most delivery teams are decidedly not value management experts (argue if you will but do YOU really want to study cost benefit analysis of social media strategies, tools and techniques, or would you rather be learning Swift?). Being a truly great engineer/developer is a more than full time gig, don’t try and be super human.

What happens then when architects own the Form and Structure and the delivery team owns the Structure and Function? This is what we call healthy tension (that future article I am writing). It is the best of both worlds and allows Structure to Emerge, just NOT Architecture.

Over the years I have continuously written and commented on the chasm that forms between architecture teams. After 15 years of learning from members and working with them on successes and failures we know there is a relatively simple set of mechanisms by which an architecture team can succeed almost every time. At Iasa we call this Engagement Model maturity. And we study successes to find repeatable patterns. For example, we know almost conclusively, that architecture teams that are only governance focused will fail, generally on a 2-3 year timeline. Similarly enterprise architecture teams that are focused on service reuse or enterprise modeling will also fail, but on a quicker timeline. When I say fail, I do not always mean that they will be fired. Simply that the initiative and funding that started the program will be dried up and they will be re-purposed. But in each of these initiatives there are a number of different ‘levers’ which if pulled properly will lead to success. These change as the organization grows in maturity.

Many of my friends in the thought leadership know that I am not of fan of enterprise architecture in a low maturity setting. While that is generally true, again it will depend on what your organization calls enterprise architecture (most mean either solution architecture for big projects, business architecture for strategic planning, or governance). But for the sake of clarity I will be using definitions and concepts from the ITABoK which allows us to use the same words for the same purposes. So by enterprise architecture I am refering a) to leadership in business technology strategy, b) participation in pure business strategy throughout the enterprise, and c) effective solution delivery with measured value change. This is an extremely mature concept especially when you begin to understand that effective EA actually translates to effective practice in BIISS (Business, Information, Infrastructure, Software, and Solution) architecture practice. It appears that enterprise architects can only be guaranteed to succeed when these specialists are successful. Hence, my concern over an EA function in low maturity architecture organizations.

This article is about getting it right. What do you need to do to make architecture a practical, high valued capability? The answer lies in a few secrets:

1. Start Bottom-Up and Expand Success Slowly: The teams that succeed are the ones repeating successes and building credibility while reducing risk. Your architects need to demonstrate that things are better with them, that they add value, that they deliver innovation. The credibility (and quite frankly satisfaction) that come from driving product success is significantly more important than dreaming big but accomplishing little. You will need this credibility as a business ‘owner’ when you are fighting the really tough fights during later stages of maturity. Once you have delivered successfully on projects and built that business credibility, you can start looking for program level roadmaps and strategies. This also means don’t scale up too quickly. Yes, I know your project was successful, that doesn’t mean every other project needs to use your architecture!
2. Focus on Professionals: This should not really have to be said, but there is a lot of hype out there. Think about this scenario. You go to the hospital, but there are no doctors there. All the other roles are in place, from hospital administration to x-ray technicians. How long do you stay? My guess is, not long. The skills needed to be an architect are not inherent nor should they be cobbled together from those who have another primary and deeply important role to fill. They grow from practice, and you don’t get that practice from being a developer or a project manager. You get it from being an architect. There is a great deal of industry push to have the team be the architect, and it is possible for it to be minimally successful. In fact Iasa has a term for it called The Extended Team Model. Generally, organizations fail at this method and ultimately the teams suffer. I will be expanding on this in a future post. For the time being focus on training your architects and requiring them to be experientially certified. Bring Iasa in to help with this if you need to do so. Also remember, that having a professional means that the professional is in charge of decisions and sink or swim with the project/program/product success or failure. You should provide peer interaction, review and assessment, as well as mentoring, but professionals are not industrial line workers, they should be given maximum leeway for success.
3. Keep Project Assignments Reasonable: The number one reason architects fail in my opinion is they are expected to do more than a person is capable of doing. You cannot be proactive on more than 3 projects and really only one of any significant scope and complexity. The moment you assign architects to more than they can be proactive on, they fall into a governance only role and will ultimately fail. Solution Architects should have 1 top priority and potentially mentor someone on up to 2 lesser priorities if you want the architect function to work. Even if that means you only have architects on 10% of your projects, they will be massively more successful and will lead to demand for more architects. If you need to, imagine paying a building architect who shows up every 6 mo and spends a day on your site.
4. Keep the Community Together: This one is absolutely essential and almost every organization I work with needs to work on it. The architecture team is not a reporting structure. You must connect the entire architecture practice together. For example, off the top of your head you should be able to a) tell me the exact number of architects in your organization (and service partner), b) know the last time you met all of them virtually or in person, c) have them on a live communication channel like slack or yammer, d) know who is what level against a rigorous experiential scale, e) be able to call in a one up and one over consult at any time. Those are fantastic starting points for keeping your community alive and connected but are absolutely the most basic. More advanced topics in community and engagement will be coming in a future installment.
5. Treat Architecture Descriptions as Communication and Thinking Tools Not Documentation: Architecture is not documentation. It is for thinking (strategy) and communication (execution). That doesn’t mean you throw everything away of course and only move to a white board (though that can be interesting). You should be keeping only enough architecture descriptions to allow another qualified architect to understand your ‘thinking’ (decision making process) so as to take over if you get hit by a bus. The rest of architecture is communication and these things can be thrown away after they have served their purpose.
6. All Architects Must Have Projects/Products: The chief of medicine still sees patients for a reason. You probably would not want to see them if they hadn’t. At some point, if you are not delivering, you become incapable of functioning as an architect. This means an architect teams’ engagement model should provide a means for all architects to deliver value in a similar way whether they are associate architects or chief architects. There are a number of benefits of this model. Architects do not lose their delivery capability. They are not seen as ivory tower and they avoid over-focusing on governance roles.
7. Eat Lunch With the Salespeople: I use this as shorthand to describe the most valuable architecture teams. Architects often cannot get out of the IT optimization mindset. There is value in cleaning up the IT shop if it is very antiquated or unable to deliver stably, but the real value of architecture is digital transformation and business outcome driven. There really is no reason to have yet another team working on IT optimization. Frankly, if the IT department cannot deliver on best practices, there probably is little reason to have an architecture team. This principle is also specific. I have lunch with sales people because they are the most customer/outcome driven. They give me Ideas (capitalization intended). In fact I got my first chief architect title from a project I sponsored based on a conversation with a sales person. This principle also points out that architecture doesn’t happen at your desk. More and better pictures are not going to transform the enterprise. Stop modeling and start communicate with business owners until you think like them.
8. Be With Your Team(s): If you hired a building architect who had never built a building, you would likely fire them. If they never showed up at the job site, the house would likely not come out looking like what you want. Great architects put their desks with their teams. We will explore this further on my next emergent design article, but architects should not be sequestered separate from the people using their designs. My estimate is that 30-50% of my time will be with my teams. As complexity increases and you have larger teams you need more architects to make this principle work.
9. Never Lose Your Business AND Technical Skills: Business architects with no technical skill are not architects they are simply business people. Technical architects without business skill are not architects, they are simply technologists. This is the fundamental principle of the ITABoK capability model. Keep in mind that does not mean that you primary daily activity will be technical or business, but architect teams that lose one or the other generally fail quickly and spectacularly. The ITABoK ensures that an architect remains a business technology strategist.
10. Write Business Cases: This is my number one ‘sniff test’ for architecture teams. If they are regularly authoring business cases they are transformation agents not governance focused. There are many benefits to this. Writing a business case requires you to think of business outcomes, not just IT optimization. It ensures that business units see that the architects are idea engines for positive business change.

Agile Business Case

Working Page for the Engagement Model Working Group – All Materials are DRAFT.
According to the DSDM Agile Project Framework an outline of an Agile Business Case might include a statement of:

• The business vision of success
• The scope and objectives of the proposed project
• High-level assumptions, dependencies and risk that may impact project viability
• Any alternatives that were considered and rejected
• The major deliverables of the proposed project
• High-level costs and benefits of the project

What differs an agile business case from any other business case? It might be that within agile, a business case is an evolutionary product.

Business Valuation

Business valuation is an important skill within the capabilities of the Iasa ITABoK. As mentioned above, a high-level idea of the costs and benefits outcome of the project is expected to be a part of a business case statement. And that might be expressed through business valuation techniques. And business valuation might be a tool to validate a business case as well.

A rather new technique has grown within agile development for prioritization called weighted shortest job first (WSJF). WSJF has also been adopted as a core practice in the Scaled Agile Framework (SAFe). WSJF is based upon a concept called cost of delay, which is a way to coomunicate the impact of time on our expected business outcome. Hence it becomes a risk management tool, or actually rather a tool to hedge risk.

What are the elements and how do you calculate WSJF? Below is a small example:

Cost of delay is defined of business value + time criticality + risk reduction, and WSJF is calculated by dividing cost of delay with job size. Hence the calculated WSJF value of Feature #1 is higher and could be prioritized.

But where do the values come from? Since we within agile and lean work in a continous flow and WSJF main purpose is prioritization, we might as well use relative numbers and sizing. A technique called planning poker has been used for cost estimation (ie job size element above) within the agile community since quite long. Actually you could use that technique for any business value element as well.

But the use of fictitious numbers and up-front estimation has also been critized within the agile community lately. The reason for that is that there’s to much guessing involved and estimates are taken for granted as the actual truth. In fact, a whole movement has grown in the name of a Twitter hashtag called #NoEstimates. But rather than saying that estimates are useless, the idea is to track velocity over time and base estimates, or rather forecasts, on actual numbers.

And what if we could put actual numbers in the WSJF table above? Actually we should strive for actual numbers in our business valuations as far as we can. Business values doesn’t necessarily have to be expressed in monetary terms. And as a matter of fact, we can as architects do a lot more better within our own toolbox. As architects we’re the one and only advocates of the quality attributes. Those should be managed and monitored, for instance collecting metrics such as performance counters, audit logs etc, as a basis for business valuation.

You could use the WSJF prioritization technique at any abstraction level. Prioritize user stories in your product backlog at the team level, features and capabilities at the program level, as well as your product portfolio at the corporate level.

Related Topics and Resources

DSDM Agile Project Framework Products – Agile Business Consortium
Business Valuation – Iasa ITABoK Capability Guidebook
Investment Prioritization and Planning – Iasa ITABoK Capability Guidebook
Weighted Shortest Job First in SAFe – Scaled Agile Framework
Cost of Delay – Wikipedia
Probabilistic Forecasting – Troy Magennis
The #NoEstimates Movement – Barry Overeem
Risk Management – Iasa ITABoK Capability Guidebook
What Is Planning Poker? – Mike Cohn
Quality Attributes – Iasa ITABoK Capability Guidebook

So you thought Agile was simple and easy?

Ever heard that Agile and Scrum are the same thing? Perhaps that was your impression as well? This comprehensive illustration from Lynne Cazaly could possilby help in dispelling that myth:

As you can see from the picture there’s around 40 different agile methods or frameworks. They’re all in the range from simple principles or practices to fully fledged software development frameworks.

….

So called hybrid frameworks has gained attraction in the last couple of years. Among those DAD, SAFe and LeSS are among the best known…..

Product over Project

A project is a way to organize work. However, in many organizations projects has become an end in itself….

What’s the problem with projects then? There are mainly two reasons:

• The division between project and maintenance leads to “handover” and loss of knowledge

The best way to maintain a software product is to have the same people maintaining it, as those who created it. So why not start maintaining from day one of production creation?

• Managers tend to “manage” resources and assign people to projects based on specialization

“Respect for people” is an important principle of lean. When you manage people like a “resource” there’s little room for respect of the individual.

Why does this matter to architects and the way they engage within an organization?

Emergent architecture and the value proposition

Can architecture really emerge?  Some form, function and structure stuff here….

Agile Modeling

Agile modeling…..Agile modeling poster

Paul Preiss is the CEO and Founder of Iasa Global, one of the largest Enterprise and IT architect associations in the world. Through his time at Iasa, Paul has taken the association from a single user group in Austin Tx to an international organization with chapters in over 25 countries. Paul’s vision is a unified architecture […]

Peter Rombouts from Sogeti joins me to discuss the hottest trends in architecture.

An enterprise architecture team has a tall order getting a digital transformation program off the ground. We met up with Gari Garcia, Enterprise Architect IAG GBS, to discuss. We covered a range of great topics including digital strategy formation and development, PMO integration, innovation management, execution and delivery as well as architecture team building.

Click HERE to download the presentation PDF

by Mark Lines

Despite claims to the contrary, the need for governance does not disappear for agile projects. Your project sponsors have a right to know the status of the health and risk of their investments. But trying to blend traditional agile methods such as Scrum with traditional stage gate approaches can cause frustration for both project teams and their stakeholders. Disciplined Agile Delivery (DAD) provides straightforward and common sense ideas for applying governance in a lightweight fashion for agile projects. DAD has been adopted organization-wide in some very large companies and in many cases the primary motivations have been related to its hybrid method approach as well as the built-in governance that it provides.

In this talk Mark reviews the four DAD lifecycles along with their associated phases and milestones. He will explain which milestones are highly recommended vs those that are considered optional. He will show how a lightweight Vision statement created in Inception can be used as a governance mechanism for moderating uncontrolled change that often happens on agile projects. Mark will share stories and tips about how to effectively apply these concepts to avoid late projects surprises.

————————————————————————————————————————————————————————————————

Mark Lines is co-creator of the Disciplined Agile Delivery (DAD) process framework and an Agile Coach with over 25 years of experience delivering software solutions across many industries. He specializes in helping organizations around the world with enterprise agile/lean transformations and adoption, writes for many publications, and is a frequent speaker at conferences worldwide.

As Managing Partner at Scott Ambler + Associates, he delivers workshops on DAD as well as other agile topics such as Disciplined Product Ownership. He also provides agile coaching and mentoring services for executives, project teams, and business stakeholders. He blogs about DAD at www.DisciplinedAgileDelivery.com and is co-founder of the Disciplined Agile Consortium (www.disciplinedagileconsortium.org).

I had the pleasure today of working today with Novak Ratkovic on a project related to architect education. Novak is a brilliant guy who asks tough questions. Exactly the type that I like the most. His question today was based on the 1 day Enterprise Architect Mindset class we will be launching shortly. His question revolved around the Iasa definition for architecture. I kept describing the definition of architecture as a practice and he wanted to understand more about architecture as a noun.

Iasa Architecture Definition

1. The art and science and science of designing and delivering valuable technology strategy.
2. A business technology strategy; any document which describes a technology strategy which creates measured value for a customer, client or employer.
3. The architect profession.

First, you might notice that the definition is, in fact, three definitions, though I will continue to use it in the singular as in the definition of the term medicine. This definition (set of definitions) was not arrived at lightly, and while it is reasonably simple, it is complex in both nuance, implementations and relationships. In fact, you will find that it completely flies in the face of both standards and much of common (not best) practice.

The Iasa definition combats the notion that architecture is simply design of a system (based on systems theory where system is more than technology) and does so for very specific reasons, most of which I will not address in this post but will do so later. The international standard definition for information and technology related architecture is captured in ISO 42010.

ISO 42010 Architecture Definition

“(The) fundamental concepts or properties of a system in its environment embodied in its elements, relationships, and in the principles of its design and evolution”

As you can see there are some serious differences between that definition and the Iasa definition. But if you look in practice and in depth, you will find that the Iasa definition provides signficantly more clarity for practicing architects as well as signficantly more depth of practice over time. Effectively the Iasa definition is better for us as a profession and more accurately reflects a fundamental principle of our beliefs, that the architect profession is distinct (from engineering and other roles) in its ability to create true architectures. It also lays a foundation for the practice of architecture including specializations such as business and information architecture.

How is this true? First, and please pardon me for saying it, but the ISO definition does not solve a problem that is societal or distinct from other fields. We see professionals because they do something for us that is important. We see a doctor because they ‘cure’ us. We see a lawyer to ‘represent’ us. We see a building architect to ‘build’ for us. Each of these is a problem that we cannot solve for ourselves. At Iasa we have made that problem/solution relationship clear. Engineers are fully capable of designing the properties of a system in its environment. But do they create business technology strategy? In rare instances, yes. But on the whole they create systems engineering designs which fulfil the ISO definition but not the Iasa definition. This is absolutely critical in definiing the value of employing architects AND engineers/developers on a software system or the equivalent on a operations, infrastructure or information system, but it has the FURTHER benefit of retaining it’s value when including business and enterprise architects!

Years ago we created a reference model which only made it to alpha draft status. This included many practicioners and thought leaders of the time. But at the core of the model was a critical difference, that makes all the difference for architects as a profession. Here is a relevant portion of that model (note: this is neither complete or rigorous as I just started moving it to lucidchart for the purpose of this blog). The FRM will be rolled into the ITABoK effort and will provide a significantly more comprehensive model than the ISO standard.

It also enables the architect to interact with the entire life-cycle of an idea all the way through exploit (commit, build, run, exploit) and provides a common interaction point from strategy through change management.

As you can see, the connections based on architecture being a strategy as apposed to an attribute of a system means that an architecture is what an architect creates to describe a strategy. A good architecture is one where that strategy has been executed and measured and value has been created.

As I said, simple, yet nuanced. But extremely powerful in defining a baseline for a valuable profession as opposed to a role.

Iasa CEO and Founder, Paul Preiss, gives a great white board session to help visualize some aspects of Agile.

by Scott Ambler

Architecture is so important on agile teams that we address it continuously throughout the lifecycle.  Interestingly, the most effective solution and enterprise architects are those that work in a collaborative and evolutionary (agile) manner.  In this presentation Scott Ambler works through how architecture practices are addressed continuously throughout Disciplined Agile development and describes pragmatic practices for doing so.  He also overviews how disciplined agile teams work closely with enterprise architects in a light-weight, streamlined manner.  Most importantly, these agile approaches enjoy a greater level of success as compared to traditional ones.

Click HERE to view the presentation

by Alex Randell

Working agile does not provide benefit if we are simply working on the wrong things in an agile manner. If architecture is not considered, we are in peril of not understanding an organization’s strategies, objectives, and value proposition; a problem that can be compounded when agile is scaled, such as with SAFe. This session will demonstrate how practitioners of business architecture can leverage tools such as value streams, capabilities, and strategies in an agile or SAFe environment to amplify the power of both the architecture and the agile practice.

Click HERE to view the presentation

Agile Business Case

Working Page for the Engagement Model Working Group – All Materials are DRAFT.
According to the DSDM Agile Project Framework an outline of an Agile Business Case might include a statement of:

• The business vision of success
• The scope and objectives of the proposed project
• High-level assumptions, dependencies and risk that may impact project viability
• Any alternatives that were considered and rejected
• The major deliverables of the proposed project
• High-level costs and benefits of the project

What differs an agile business case from any other business case? It might be that within agile, a business case is an evolutionary product.

Business Valuation

Business valuation is an important skill within the capabilities of the Iasa ITABoK. As mentioned above, a high-level idea of the costs and benefits outcome of the project is expected to be a part of a business case statement. And that might be expressed through business valuation techniques. And business valuation might be a tool to validate a business case as well.

A rather new technique has grown within agile development for prioritization called weighted shortest job first (WSJF). WSJF has also been adopted as a core practice in the Scaled Agile Framework (SAFe). WSJF is based upon a concept called cost of delay, which is a way to coomunicate the impact of time on our expected business outcome. Hence it becomes a risk management tool, or actually rather a tool to hedge risk.

What are the elements and how do you calculate WSJF? Below is a small example:

Cost of delay is defined of business value + time criticality + risk reduction, and WSJF is calculated by dividing cost of delay with job size. Hence the calculated WSJF value of Feature #1 is higher and could be prioritized.

But where do the values come from? Since we within agile and lean work in a continous flow and WSJF main purpose is prioritization, we might as well use relative numbers and sizing. A technique called planning poker has been used for cost estimation (ie job size element above) within the agile community since quite long. Actually you could use that technique for any business value element as well.

But the use of fictitious numbers and up-front estimation has also been critized within the agile community lately. The reason for that is that there’s to much guessing involved and estimates are taken for granted as the actual truth. In fact, a whole movement has grown in the name of a Twitter hashtag called #NoEstimates. But rather than saying that estimates are useless, the idea is to track velocity over time and base estimates, or rather forecasts, on actual numbers.

And what if we could put actual numbers in the WSJF table above? Actually we should strive for actual numbers in our business valuations as far as we can. Business values doesn’t necessarily have to be expressed in monetary terms. And as a matter of fact, we can as architects do a lot more better within our own toolbox. As architects we’re the one and only advocates of the quality attributes. Those should be managed and monitored, for instance collecting metrics such as performance counters, audit logs etc, as a basis for business valuation.

You could use the WSJF prioritization technique at any abstraction level. Prioritize user stories in your product backlog at the team level, features and capabilities at the program level, as well as your product portfolio at the corporate level.

Related Topics and Resources

DSDM Agile Project Framework Products – Agile Business Consortium
Business Valuation – Iasa ITABoK Capability Guidebook
Investment Prioritization and Planning – Iasa ITABoK Capability Guidebook
Weighted Shortest Job First in SAFe – Scaled Agile Framework
Cost of Delay – Wikipedia
Probabilistic Forecasting – Troy Magennis
The #NoEstimates Movement – Barry Overeem
Risk Management – Iasa ITABoK Capability Guidebook
What Is Planning Poker? – Mike Cohn
Quality Attributes – Iasa ITABoK Capability Guidebook