Click HERE to download the Presentation PDF

by Lynne Cazaly

Making sense is the most significant capability for the future of work.
If we are to adapt to the VUCA (volatility, uncertainty, complexity and ambiguity) that constant change brings… we will need to generate insights, ingenuity and ideas that enable us to respond and adapt in times of massive change. Lynne Cazaly presents her three step process of sense making and how to bring this to work in teams, units, organisations and sectors. Sharing insights from her book ‘Making Sense’, Lynne will share some of the thinking, mapping and acting tools for sense making. These come from over 103 different tools, techniques, templates and thought starters she has created.

Lynne Cazaly is a keynote speaker, author and adviser. She is the author of the books:
§ Making Sense: A Handbook for the Future of Work
§ Create Change: How to apply innovation in an era of uncertainty, and
§ Visual Mojo: How to capture thinking, convey information and collaborate using visuals.

She works with executives, senior leaders and teams on major change and transformation projects. These include technology, Agile and UX projects. She helps people distil their thinking, apply ideas and innovation and boost the engagement and collaboration effectiveness of teams.
Lynne assists organizations with creative and engaging facilitated workshops, skills development in creative and innovative thinking and she works with people to help them unlock the ‘entrepreneur inside’.
Lynne is an experienced board director and chair and is a global keynote speaker and an executive facilitator. She is on the faculty of Thought Leaders Business School and has presented at Agile international conferences and events in Australia, USA, India, Singapore and New Zealand.

Click HERE to download presentation PDF

Alex Yakyma will describe how complex solutions are built using Scaled Agile Framework. Alex will discuss critical aspects of the framework as well as its actual implementation scenarios in the field. The topics will include:
· Organizing around value
· Establishing Lean-Agile governance model in large value streams
· Managing solution portfolio and flow of enterprise initiatives
· Improving flow via continuous attention to architectural enablement
· Building successful SAFe rollout strategy
Finally, Alex will also describe how to apply the modularity and customizability of SAFe to each organization’s context.
Attendees will acquire insights on how to build complex solutions with Lean and Agile practices at enterprise scale.

Alex Yakyma is a SAFe methodologist, trainer, and principal consultant who has been involved with the development and field implementations of the Scaled Agile Framework since its inception. Alex’s broad prior experience as a developer, development manager and program manager in highly distributed multi-cultural environments provides the experience needed to assist enterprises with improving their system development capabilities at the program, multi-program, and portfolio level.

Click HERE to download presentation PDF

by Johanna Rothman

Agile changes how we develop products. We no longer have the big design up front, or even know enough about what the product might do at the beginning. How can you continue to create great products that people will want, and that will be coherent? You can change your perspective from serving the product to serving the people.
When you include servant leadership for the people on the teams, you continue your work as a traditional architect: shepherd the business value of the architecture, explore possibilities so the teams can implement, and create new ideas for how the product(s) will fit together. In addition, you coach and serve the people on the teams. You no longer have to be the only one with the vision. You can share the vision.
This challenges everyone: you and your sense of worth; the teams and how they work with you; and the organization for who does what, how, and how to compensate everyone.
In this talk, Johanna Rothman will discuss how agile creates opportunities for architects, and what servant leadership can look like for architects.

Johanna Rothman, known as the “Pragmatic Manager,” provides frank advice for your tough problems. She helps leaders and teams see problems and resolve risks and manage their product development.
Johanna was the Agile 2009 conference chair. She is the current agileconnection.com technical editor. Johanna is the author of these books:
– Agile and Lean Program Management: Scaling Collaboration Across the Organization
– Project Portfolio Tips: Twelve Ideas for Focusing on the Work You Need to Start & Finish
– Diving for Hidden Treasures: Finding the Value in Your Project Portfolio
– Predicting the Unpredictable: Pragmatic Approaches to Estimating Cost or Schedule
– Manage Your Job Search
– Hiring Geeks That Fit
– Manage Your Project Portfolio: Increase Your Capacity and Finish More Projects
– The 2008 Jolt Productivity award-winning Manage It! Your Guide to Modern, Pragmatic Project Management
– Behind Closed Doors: Secrets of Great Management
– Hiring the Best Knowledge Workers, Techies & Nerds: The Secrets and Science of Hiring Technical People
She writes columns for techwell.com and projectmanagment.com, and writes two blogs on her web site, jrothman.com, as well as a blog on createadaptablelife.com.

Click HERE to download presentation PDF

by Claudio Peronne

Agile is about rapid evolution, not mindless conformance to popular methodology “ceremonies”. If you had perfect architectures, perfect processes, perfect organizations, perfect customers… you would not need Agile at all. At its core, Agile recognizes the complexity of our world and wisely suggests to embrace change using an “inspect & adapt” approach to development. To what extremes can you bring this idea further?

Improvement without change is impossible. Yet, most people think about change as big, slow and scary. But what if you could make it infinitely small and learn to evolve fast, almost as fast as some of the most adaptive microorganisms on earth?

Enter PopcornFlow – a mindset, new principles and actionable techniques to help you introduce fast change and make better decisions through the deliberate design and execution of a continuous stream of small, traceable and safe-to-fail experiments.

Don’t get too comfortable with your own cozy routines and mental cages. For a new revolution is now on your doorstep.

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

Claudio Perrone brings models, experience and options to help ambitious companies build fast, learn faster, and thrive in today’s global marketplace. Claudio is an internationally-recognized Lean & Agile management consultant, entrepreneur and startup strategist, based in Dublin, Ireland.

In his career, he has been playing key roles in Lean & Agile transformations for global organizations and fast-growing technology startups. He is a Fellow of the Lean Systems Society, author of A3 Thinker (a family of tools based on Toyota’s Lean management approach), and the inventor of PopcornFlow, a next-generation model to introduce personal, team and organizational change through ultra-rapid experimentation.

Follow @agilesensei

by Mike Vincent

With Scrum and other forms of agile software development we focus on incrementally evolving architecture one sprint or iteration at a time and avoid the potential waste of big design up front. What’s this really mean? We’ll talk about pragmatically doing just enough just in time while delivering a potentially shippable increment of working software every sprint.
So where and when do we plan, and how much? What about the big picture? How does our architecture fit within the enterprise? How does it facilitate our business objectives? How do we manage risk? And, what about all the details? What tools are we using, what standards are we adhering to, how are we managing maintainability and all the other NFR’s? Is everything integrating together nicely? And, what is role of the solution/enterprise architect in an agile world?
This session is all about helping you understand architecture in the world of today’s agile software development.

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

Mike Vincent is a veteran software entrepreneur based in Orange County, California and Kona, Hawaii. He currently provides clients throughout North America with application lifecycle management training, Scrum coaching, and enterprise/solution architecture consultation primarily focusing on Microsoft technologies. He has been in the software business for over 30 years in addition to marketing management and construction management positions. Actively involved in the user group community since the early 90’s, Mike is a frequent presenter at developer events including Microsoft TechEd and PDC. He is a Visual Studio Application Lifecycle Management MVP, Professional Scrum Master, Scrum Product Owner, Scrum Developer and Scaled Professional Scrum Trainer.

Click HERE to download Presentation PDF

by Todd Kamens

Success AFTER Scrum Training: 6 Best Practices
Learn from Industry leaders how to make your training Stick
Do you ask yourself:
“How is this going to work? We don’t have anyone with experience with Scrum in my company.”
“Our company philosophy \ culture is at odds with the core Agile values”
“As a Scrum Master, how will I facilitate the Scrum Meetings?”
“How can I get Management Support to do this?”
“This framework would be great but I am not sure my team is willing to follow Scrum.”
“How in the world are we going to write User Stories?”
“My Business team is going to love this, but how will we be able to have a single Product Owner with time available to support the team?”
If any of these symptoms describe how you’re feeling, join Guidance Technology’s Best Practices Webinar where you’ll discover…
… The basic stages of learning that will help you understand your team better…
… 6 Best Practices from a leading Education provider that will help to ensure your training Sticks after the class ends…
… And much more…
Learn how to make your training Stick and deliver performance improvements that are measurable.

Click HERE to download presentation PDF

by Hayim Makabee

This talk tries to answer the question: “How much Design Up Front should be done in an Agile project?” Hayim presents his approach of Adaptable Design Up Front (ADUF), describing it’s rationale, applications in practice and comparison to other approaches such as Emergent Design.

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

Hayim Makabee was born in Rio de Janeiro. He immigrated to Israel in 1992 and completed his M.Sc. studies on Computer Sciences at the Technion. Since then he worked for several hi-tech companies, including also some start-ups. Currently he is a Predictive Analytics expert at Pontis. He is also a co-founder of the International Association of Software Architects (IASA) in Israel. Hayim is the author of a book about Object-Oriented Programming and has published papers in the fields of Software Engineering, Distributed Systems, Genetic Algorithms and Recommender Systems.

by Brian Dreyer

“Agile” is frequently used as an umbrella term for new methodology. In this presentation, you will gain an understanding as to what the term Agile really means in product development, including its advantages and where it’s used.

Brian will focus his interactive presentation on the mechanics of empirical process control and how it enables a higher degree of management, better long-term planning capabilities, improved team efficiency, and improved alignment between results and the business goals of the product. There will be examples and interactive discussion that underscores several principles of Scrum – the most popular Agile framework.
Brian will also compare Agile with traditional project management techniques and talk about how to implement Agile Project Management in the workplace.

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

Brian Dreyer is a Certified Scrum Professional (CSP) and an Enterprise Agile Coach at Teradata in San Diego. Prior to joining Teradata in Jan. 2015 he was a Director, ScrumMaster and Coach with Platinum Edge INC., and a frequent speaker on agile and scrum. He’s worked with clients transitioning to agile and has been hands-on helping organizations capitalize on agile approaches to project management.

Previously as Vice President of Business Development at Climax Group, UK and as the founder of Watchdog Entertainment, Brian has worked with companies such as Mattel, Microsoft, EA, Activision,
Nintendo, Sony, Disney and is a credited Executive Producer on 17 video game titles.
Prior to Climax Group, Mr. Dreyer was Vice President of Sales and Marketing with a Beverly Hills based production company, The Machine, where he was responsible for company’s entertainment marketing strategies, as well as media technology partnerships.

Prior to joining The Machine, Mr. Dreyer founded a management-consulting firm, focused on project management, strategic marketing, business development and information technology governance, drawing upon his 15 plus years of experience.

Brian has also held a variety of executive positions with companies such as Amp Incorporated (now Tyco), Avnet, TechSpace, Syncata and technology analyst firm Gartner. He’s alumni of Saint Joseph’s University, Philadelphia.

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

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.

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.

Below is a canvas that allows you to navigate through descriptions of the lean and agile adoption of the engagement model:

Agile Modeling and architecture artefacts

Agile modeling…..agile modeling poster

Agile Business Case

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. The business case as described in the DSDM Agile Project Management Framework:

Agile Project Framework Products

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).

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 and architecture artefacts

Agile modeling…..agile modeling poster