This is a good reminder: change can be fun or exciting.
Change isn’t always bad. To add my own opinion to Mike’s excellent post, change is how we grow. If we don’t change, that is death. It is stasis that we should fear!!!
From Mike’s article:
If you are a person who helps others to embrace or live through change (whatever your interpretation of change is)….
… consider the damage you are causing by inspiring fear where it simply may not be appropriate or necessary.Learn more about our Scrum and Agile training sessions on WorldMindware.comPlease share!
The post Link: Change Can be Fun or Exciting by Mike Caspar appeared first on Agile Advice.
A conversation with Enterprise Transformation Consultant Jeff Howey about Agile practices being used outside of IT organizations.How did you start working in HR?
When I started working with the HR business organization, it was actually helpful that most of the technology teams were individually running with a basic form of Scrum or Kanban already. The leaders of the business area understood the value of visibility, predictability and adaptability that were improving through the practice of Agile in the technology teams. They knew they also wanted predictability, to focus on value, to make and meet promises out of the HR business unit. So they asked me to help their teams in Human Resources. Teams like recruiting, learning and development, compensation and various other groups within the actual HR services area practice some of those agile techniques.What were some challenges working with the non-IT groups?
One of the key things that was interesting was that I had to change some of the language that I’m used to using as an agile coach. For instance, to use the word Scrum with someone whose job has been helping to coach and lead people in conflict resolution and explain its roots in the somewhat violent game of Rugby, created a bit of a angst within the group. So I had to make some simple changes. Instead of Kanban, I talked to them about a visual management system. Our goal as a team is to know all the work we are doing and manage it in a visual way so we can see it where it’s at, where it’s moving, where it might be getting stuck. That resonated. In a non-technical environment it’s the concepts that apply and the language that we use can sometimes get in the way.Besides language were there other impediments that you found?
There were some obvious problems. Pretend you’re a caseworker on an employee relations team, that is dealing with an employee that just kicked their boss. Now the system we are trying to create is a visual management system where everything is on cards and everyone can see what you’re working on. The last thing you want to do is make a card that the whole organization can see that says that someone has kicked their boss and is going to get fired. There is a limit, sometimes even legally, to the amount of transparency that you can have.
There were also some teams that simply opted out because they had ideas around privacy and privileged information and things that are confidential or just messy which they felt couldn’t be managed this way. And a few individuals who were specialists that felt it was too much overhead to be managed this way.How did you address these impediments?
Let’s start with the teams that adopted it easily. One of the concerns of the teams was specialization, “I’m the one that does this and you’re the one that does that.” When I asked why, the answer was more often than not, “because that’s the way it’s always been.” So I began to discuss why you might want to share responsibilities, things like succession planning, back-ups for vacations and illness and introduced the concept of pairing. The patterns that we see in technology we are able to apply to a non-technical organization. People in single-threaded roles, making more functional and cross-cutting teams with more experience, dealing with dependencies on those roles. The problems we are dealing with are “people problems” that are not that different from the problems we deal with in the technical world. There are different platforms, different ideas and different language that we are using but it’s honestly the same problem that we are trying to solve.
This is an excerpt from The Simple Leader: Personal and Professional Leadership at the Nexus of Lean and Zen
There are no big problems, just a lot of little problems.
– Henry Ford
Kaizen is probably the most important concept in the Toyota Production System. The word kaizen can be broken into its two components: kai, meaning “change,” and zen, meaning “good.” It was brought to the West in 1986, when Masaaki Imai wrote Kaizen: The Key to Japan’s Success. I agree with Imai and others such as Bob Emiliani that say “there can be no Lean without kaizen.”
Although kaizen is generally thought of as large numbers of small improvements that add up to create a large overall change, it is important to understand that this is not a restriction. Kaizen can be small activities by individuals, small ongoing team-based activities, focused multiple-day events to make rapid, significant improvements, or large improvement projects driven by executive staff.
In most companies, problem solving and improvement starts by having a team of managers carve an hour or two a week out of their schedules. Over several weeks, they discuss problems, typically in a conference room. They brainstorm ideas for changes or improvements and make detailed plans about how to implement their ideas. This process takes a lot of time, and may or may not actually solve any problems.
With kaizen, less time is spent planning and more time is spent experimenting. The planning takes place at the gemba, typically by the people directly involved in the process. These people have a better understanding of what is actually happening on the floor and are more likely to take ownership in the improvement process when they are included in the kaizen. Each individual experiment is relatively small, so there is a low risk that any one change will cause large negative impacts. Over time, the changes, especially the learning from continually planning, doing, studying, and revising, create large cumulative positive effects.
In addition to the individual or small-team kaizen activity with small experiments, Lean organizations also utilize kaizen events in order to aim for more radical changes. The events are generally three to five days long, with the entire team fully dedicated to the activity. During a kaizen event, the first day is spent planning, the next couple days are spent doing, and the final days are spent studying and acting on the results. Kaizen events can create very significant improvement in a short period of time. They are especially effective when someone from the senior leadership team helps facilitate the event, allowing approvals to purchase equipment or modify processes to be expedited.
Kaizen and kaizen events follow the PDSA cycle we previously discussed. The steps are:
- Define the problem. (Plan)
- Document the current state. (Plan)
- Determine the desired future state with measurable targets. (Plan)
- Identify solutions or improvements. (Plan)
- Develop the plan. (Plan)
- Implement the plan. (Do)
- Study the results and compare to the plan, targets, and desired future state. (Study)
- Document the change in standard work, or use what was learned to create the next experiment. (Adjust)
- Document and publicize the kaizen activity. (Adjust)
The last step documenting and publicizing the kaizen activity—is important and should not be neglected. Many Lean organizations have kaizen boards, kaizen newspapers, or kaizen “wall of fame” areas where such activities are made visible. This is both motivating to others and can inspire other ideas for improvement.
Another critical concept of kaizen, often missed by even the best Lean organizations, is “unlearning.” Chihiro Nakao said, “You have to go back to zero. Put yourself under dire circumstances to think differently.” Many business writers have discussed the “learning organization,” but unlearning old standards, methods, or even rationales is just as important, if not more. Learn, and unlearn. Remember the Zen concept of beginner’s mind?
The role of the leader in kaizen is critical. You must demonstrate and explain why kaizen is important for your organization. You should lead by example and personally lead both big and small kaizen. Ask your employees to participate in kaizen activity and support it by providing time, training, and mentoring. What a great way to get to know the folks at the gemba, and also to teach them about PDSA and improvement methods! Ask your leadership team to do the same. When you implement kaizen, be careful about creating arbitrary goals for the number of kaizen activities; instead, create a culture where kaizen is supported. Finally, celebrate kaizen, especially when learning occurs from failure. Learning is an improvement in itself.
When using kaizen, it is important to not sacrifice time for perfection. Remember, the goal is to create ongoing incremental improvements, not to find the perfect one-time solution.
Scrum is the lightweight project management method which is most often utilized in applying the principles of Agile to software delivery. Within the Scrum framework, volumes have been written about the roles of the Product Owner and Scrum Master. What about the Development Team?
A development team is composed of individuals, each with their own histories and unique set of skills. Very often they have worked in company with others on loose teams but have primarily contributed as individuals to software projects and have been rewarded commensurate with their contribution to the success of those projects. However, in Scrum the emphasis is on delivery of potentially shippable software in short intervals as a team.
A Scrum development team is self-organizing and cross-functional. Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team. Cross-functional teams have all competencies needed to accomplish the work without depending on others not part of the team. The team model in Scrum is designed to optimize flexibility, creativity, and productivity as they plan, act, and deliver together.
The first of the twelve principles in the Agile Manifesto is, “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.” But with Scrum, the goal has been the delivery of ‘potentially shippable code’ after every sprint. So why all the excitement around DevOps? DevOps seeks to move from ‘potentially shippable’ to ‘shipped’ – and this shift requires that the development team evolve yet again.
In an article entitled “From Agile to DevOps to continuous delivery: An evolution in software delivery”, the author states that,
“With the release of Jez Humble’s breakthrough book, Continuous Delivery …, the notion of treating the entire software lifecycle as a single process—and one that could be automated— was embraced not only by startups but also by Fortune 1000 companies. This helped elevate the value of agile initiatives that were stalled and blocked and raised the stakes for software delivery as a strategic business initiative. While agile addressed the needs of developers, the investment in DevOps initiatives and CD offers businesses much higher returns—a way to truly realize the goals outlined in the Agile Manifesto and support them throughout the software delivery lifecycle.”
That a new buzzword, DevOps, has entered our vocabulary certainly seems to herald a new round of transformational initiatives which may or may not succeed as business continues to seek the chimera of competitive success. What do team members with backgrounds in development, operations, testing, analysis, architecture, infrastructure, and information security need to know to enter into this brave new world of Contiguous Delivery? What tools, processes, methods, and standards will they need to learn and incorporate into existing work flows to benefit from this evolution?
First, by way of clarification, there are three terms that are often used interchangeably, Continuous Integration, Continuous Deployment, and Continuous Delivery. Teams following Extreme Programming engineering practices have been doing Continuous Integration since the mid-nineties. Continuous Integration (CI) is a development practice that requires developers to integrate code into a shared repository several times a day. Each check-in is then verified by an automated build, allowing teams to detect problems early. Very often automated tests, unit, integration, acceptance, code quality, are included in the build to verify code quality.
The next step was the concept of continuous deployment, defined in a paper by Jez Humble again, along with Chris Read and Dan North in 2006 entitled, The Deployment Production Line (abstract available here). In this monograph they outlined an approach where not only functional code but also the environments would be created, deployed and kept under version control. This was followed by Continuous Delivery in 2011. In their most recent book, The DevOps Handbook, Gene Kim, Jez Humble, Patrick Dubois, and John Willis use a framework for implementing the positive changes needed to realize the benefits of Continuous Delivery/Deployment comprised of what they call the Three Ways. These are;
- The Principles of Flow,
- The Principles of Feedback,
- The Principles of Continual Learning and Experimentation.
It is the third principal which I believe is most important to software delivery teams as they take up the DevOps challenge.
The chart below illustrates Westrum’s model of the three types of organizational cultures. It is the Generative culture in which DevOps can flourish and make the kinds of contributions which lead to improved market share among competing businesses. We must move to a culture which encourages team members to investigate in a safe environment and thus grow in their skills.
Westrum’s 3 Organizational Cultures
In order to move to implement the strategy of Continuous Delivery we must encourage high collaboration and innovation. This means breaking down organizational barriers to team experimentation. We must move along the axis from the Pathological to the Generative.
Historic industries (i.e., automotive, steel, construction) have a tough job ahead of them as they attempt to move from long-standing practices and cultures of command and control to cultures that built on trust and innovation. Not all will be able to make the shift. Those that can’t will be left behind as Kodak was. We must stop outsourcing our skilled IT jobs to low cost areas of the world and invest in our in-house teams. IT cannot be considered a cost center anymore. Every company of any size is a software company and to stay competitive they must all see software and IT as an integral part of their market strategy, brand promise and product delivery.
So what should be our call to action? It is this: only so long as individuals feel safe within their corporate environment, and empowered to make decisions that are not countermanded by remote management, are teams capable of overcoming the challenges and seizing the opportunities now being realized by the Agile evolution to DevOps. Within that culture of safety and continual learning, skills acquisition with emerging technologies, tools and techniques must be a part of everyone’s job and a continuing goal of the business.Resources and Further Reading
“From Agile to DevOps to continuous delivery: An evolution in software delivery” TechBeacon, sited 11/8/2016.
Extreme Programming Explained: Embrace Change, Kent Beck. Addison-Wesley, 1999. Winner of the Jolt Productivity Award. (ISBN 978-0321278654)
The Deployment Production Line (Abstract). Microsoft Academic, sited 11/8/2016.
Continuous Delivery, Jez Humble and David Farely. Addison-Wesley, 2010.
The DevOps Handbook, Gene Kim, Jez Humble, Patrick Dubois, and John Willis. IT Revolution Press, 2016.
“A Topology of Organizational Culture”, Ron Westrum. BMJ Quality & Safety 13, no. 2. 2004. doi:10.1136/qshc.2003.009522.
“Barriers to Change: The Real Reason Behind the Kodak Downfall”, Kotter International. Forbes, 2012.
“Software Must Enrich Your Brand”, Forrester Research, sited 11/16/2016.
The post As Problems and Markets Evolve So Too Must Development Teams appeared first on SolutionsIQ.
If you’re thinking about agile or trying to use it, you probably started with iterations in some form. You tried (and might be still trying) to estimate what you can fit into an iteration. That’s called “pushing” work, where you commit to some number of items of work in advance.
And, if you have to service interruptions, such as support on previous projects, or support the production server, or help another project, you might find that you can’t “push” very well. You have trouble predicting what you can do every two weeks. While the iteration duration is predictable, what you predict for the content of your iterations is not predictable. And, if you try to have longer iterations, they are even less predictable.
On the other hand, you might try “pull” agile, where you set up a kanban board, visualize your flow of value, and see where you have capacity in your team and where you don’t. Flow doesn’t have the built-in notion of project/work cadence. On the other hand, it’s great for visualizing all the work and seeing where you have bottlenecks.
Iterations provide a cadence for replanning, demos, and retrospectives. That cadence, that project rhythm, helps to set everyone’s expectations about what a team can deliver and when.
Kanban provides the team a perspective on where the work is, and if the team measures it, the delays between stages of work. Kanban helps a team see its bottlenecks.
Here are some options you might consider:
- Add a kanban board that visualizes your workflow before you change anything. Gather some data about what’s happening. Are your stories quite large, so you have more pressure for more deliverables? Do you have more interruptions than you have project work?
- Reduce the iteration duration. Interruptions are a sign that you might need to change priorities. Some teams discover they can move to one-week iterations and manage the support needs.
- Ask questions such as these for incoming non-project work: “When do you need this done? Is it more or less important or valuable than the project work?”
- Make sure you are a cross-functional team. Teams can commit to finishing work in iterations. A group of people who are not interdependent have trouble committing to iterations.
Teams who use only iterations may not know the workflow they really have, or if they have more project or support/interrupting work. Adding an urgent queue might help everyone see the work. And, more explicit columns for analysis, dev & unit test, testing, waiting (as possibilities) in addition to the urgent queue might help the team see where they spend time.
Some teams try to work in two-week (or longer) iterations, but the organization needs more frequent change. Kanban might help visualize this, and allow the team to change what they commit to.
Some POs don’t realize they need to ask questions about value for all the work coming into a team. If the work bypasses a PO, that’s a problem. If the PO does not rank the work, that’s a problem. And, if the team can’t finish anything in a one-week iteration, that’s a sign of interdependencies or stories that are too large for a team. (There might be other problems. Those are the symptoms I see most often.
You can add a kanban board inside your iteration approach to agile. You might consider moving to flow entirely with specific dates for project cadence. For example, you might say, “We do demos every month on the 5th and the 19th of the month.” That would provide a cadence for your project.
You have choices about pushing work or pulling work (or both) for your project. Consider which will provide you most value.
P.S. If you or your PO has trouble making smaller stories, consider my workshop, Practical Product Ownership.
In the spirit of relentless improvement, we’re pleased to announce three significant changes to the SAFe website:1. Revised Glossary
The SAFe glossary has been updated to make it clearer, shorter, simpler and easier to read, as well as preparing it for a localization spike. The spike will cover Spanish, French and Simplified Chinese. If the spike goes well, the glossary will be translated into a total of 14 languages!2. New Resources Menu
The menu’s have been restructured. The new “resources” menu item contains:
- SAFe blog – get the latest news on SAFe and stay updated as we incremental update the framework
- Glossary – definition of all SAFe big picture terms with links to the articles
- Guidance Articles – over 20 articles that provide new and emerging areas and advanced topics
- Books on SAFe – the latest official books on SAFe
- Posters download – download a variety of posters for printing – 3 and 4 level SAFe, House of Lean, Principles and order a fabric big picture here
- Presentations and Videos download
This new menu contains:
Always be SAFe,
Richard and the SAFe Framework team
[[ This is a content summary only. Visit my website for full links, other content, and more! ]]
[[ This is a content summary only. Visit my website for full links, other content, and more! ]]
Have you heard of a MVP - Minimal Viable Pumpkin?
Minimal Viable Pumpkin (MVP)https://en.wikipedia.org/wiki/Lean_startup
As we continually improve SAFe to better meet the needs of our customers, there comes a time when it’s no longer practical to support older versions of the Framework. This is part of any technology product’s lifecycle, and it is no different with SAFe.
On December 30, 2016, all SAFe 3.0 courseware and materials will be retired. As a result, the SAFe 3.0 website (v3.scaledagileframework.com) will redirect to the 4.0 Framework site, and 3.0 courseware will no longer be available.
Though we will no longer be supporting SAFe 3.0, we recognize that there are enterprises that will continue to want the simpler ‘classic’ 3.0 version. That is why we designed SAFe 4.0 to be backwards compatible so that 3.0 users can migrate easily to the current version using the default ‘3-Level’ view of SAFe 4.0.
Our 3.0 courses have been replaced with ones that better support the benefits that can be gained with SAFe 4.0:
If you need a reminder about why you want to be practicing the latest version of SAFe, here is the rundown:Click to enlarge
Version 4 features extensive refinements to many elements of the Framework, as well as new content and guidance that helps enterprises better organize around value delivery, develop systems that include hardware and software, and improve development, coordination, and delivery of large value streams.
Below is a summary of the major content changes to SAFe; for the indepth view please refer to What’s New in SAFe 4.0.
- SAFe now supports both software and systems development
- A new Value Stream level—including new roles, activities, and artifacts—is provided for those building the world’s largest systems
- The Big Picture can be expanded or collapsed to three or four levels. The default view is the three-level version (3-Level SAFe), which is simpler and lighter weight than its 3.0 predecessor. Three-Level SAFe is backwards compatible with SAFe 3.0, so those currently operating with 3.0 can continue to do so, or migrate easily to this new version.
- With one click, the Framework expands to four levels (4-Level SAFe) to handle the most demanding needs of large value streams and complex systems development
- Enterprise Kanban systems manage the flow of work across all levels
- The SAFe Requirements Model has been updated to reflect additional backlog items and to clarify the expressions for each
- Built-in Quality practices now support software and systems development
- A new Foundations layer supports those critical underpinnings that drive the Framework and program execution
- A new Spanning palette carries roles and artifacts applicable to multiple levels, increasing modularity and customizability
- An improved main menu bar provides quick and easy access to information on SAFe training, implementation, partner support, community, resources, and more
Again, on December 30, 2016, all SAFe 3.0 courseware and materials will be retired, so make sure to migrate as soon as possible. You can learn about all the SAFe 4.0 courses at scaledagile.com/which-course. If you need support in making the transition, there are over 100 Scaled Agile Partners actively supporting SAFe 4.0 in over 35 countries, and they are ready and available to help you move to the best and latest version of SAFe.
—Dean and team
You might have noticed I have not written as much in this blog for the past couple of months as I normally do. That’s because I’ve been involved in another writing project that’s taken a ton of my time.
I’m part of the writing team for the Agile Practice Guide. The Guide is a joint venture between the Agile Alliance and the PMI. See Bridging Mindsets: Creating the Agile Practice Guide.
We work in timeboxes, iterating and incrementing over the topics in the guide. We sometimes pair-write, although we more often write and review each other’s work as a pair.
If you would like to review the guide as a subject matter expert, send me an email. You’ll have about a month to review the guide, starting in approximately January 2017. I am not sure of the dates yet, because I am not sure if we will finish all our writing when we originally thought. Yes, our project has risks!
We’ve changed the list of predefined and custom reports that could previously be found in the ‘Other Reports’ top menu. The old predefined reports from Targetprocess 2 have had their day and have now given way to the new Visual Reports Editor.
For example: to create a brand new 'Time by Person' chart, go to the 'Create' option at the bottom of the page, select Report, and then find the 'Time Spent' templates for your new report.
Custom reports are now called 'Tabular Reports.' You can still find them in their usual place: in the Reports menu in the top bar:
Lane suggestions in Board setup
The most appropriate options will now be displayed first when selecting fields for lanes in Board setup. This improvement applies to cards that have a large amount of options available for lanes, i.e. Epics, Features, User Stories, Tasks, Bugs, Requests, Test Plans, and Test Plan Runs.
- Test Run Import plugin: Test Plan selector will now be able to show more than 1000 entities at a time
- Text comments without line breaks will no longer truncate instead of moving into new line
- Fixed multiple script errors on a Timesheet if Time entity has a Targetprocess entity custom field setup
- Deleted or missing attachments will not prevent entity removal
- Bugzilla Integration: fixed a synchronization failure for some old profiles
- Fixed an internal server error in the Audit History of a program if custom field changes took place
Today I am addressing a key component to help teams succeed. Stable Teams.
Stable Teams Defined
I find that many people interpret those two words in many different ways. Here’s my definition.
A stable team is a team that stays together for ideally multiple releases or quarters. They have a few characteristics:
1. Individuals on the team only belong to one team.
2. The Team has one backlog.
3. The backlog is formed by a consistent entity.
4. The team stays together for multiple releases or quarters barring life events like illness, HR issues, etc.
Stable teams can be applied at any level in an organization. Communities of practice, agile delivery teams, programs and portfolios all have a backlog.
Plenty of studies have been done on the appropriate size of the team or how productive the teams can be if they are stable. Here are the key points:
1.Teams that stay together have a higher throughput.
2.Teams that stay together are more predictable.
3.Teams that stay together are happier.
The Softer Side
Our community is multi-dimensional in how agile is implemented. I implement a structure first approach. Some implement a cultural approach so that they change the mindset of the organization. Still others implement a practices approach where practices are taught and the teams are responsible for the outcome.
The reason I choose a structure approach is fairly straightforward. It’s not that I don’t care about culture and practices, but it’s out of respect for the longevity of the team, the culture, and the practices. I am intentionally creating a container that protects the team. Protects them from what you might ask?
With a cultural approach, the worst thing I can do is teach accountability, self-organization, and how to be a generalist and have that subverted by team members being swapped off of teams. Teams that stay together figure out how to use each others unique strengths over time. They can be responsible for their own outcome and held accountable for it too. They can figure out how to best do the job at hand. If I pull someone out of the team, that kills accountability and their self-organization is blown to bits. Go ahead and try to hold them accountable. They will hate you for the long hours they pull trying to get the work done. Respect the structure, and seek to change culture after protecting the container.
With a practices approach. The container for the team to take those practices and run with them isn’t created. The team may not be able to effectively create a working agreement or retrospect to come up with new ways to improve or implement the practice. They can attempt to self-organize, but it’s beyond their control much of the time.
So I turn to structure. If I structure the team, protect the team, and support them, they have the best chance for success. Not all teams will succeed. Some will improve slower than others. But they have a shot at changing their own culture. We can hold them accountable for their outcome because we have enabled them to do so. They can become generalists over time so when life events happen, the team can cover and prop up their team member. When attrition occurs, the team can absorb the change more readily.
Assuming that all made sense, what the heck is preventing stabilization of teams?
To list a few:
1. Focus on individual utilization.
Some organizations focus on maximizing individual utilization, they even overbook. In large PMO organizations that focus on utilization of individuals there is a sense that team members aren’t always working. This just isn’t accurate. While in the short term a team member or two can be underutilized, that is a maturity of practice issue that can be overcome. Utilization can indeed be improved. Not only that, but those people managing how much individuals are used across the organization can focus on something else because utilization is stable too. Knowing how much capital investment you have vs opex is much more valuable than scheduling someone’s percentage of work on a feature.
Kill them with fire. Actually no… some side projects make great candidates for the backlog of the organization. Providing a single source of truth gives clarity to teams. Tech Debt can be prioritized along side of features. Teams need to be able to quantify the value. That’s generally easy to teach them. In the end, they will find that they get much more done. On another note, if the team is receiving work from the side. On the down low. That needs to stop. It’s an impediment to Team Stability. Find the source, figure out why it’s happening and eradicate it. That’s not simple, people have side projects for a reason. They are trying to solve a problem. Figure out if it’s an education issue, an alignment issue, or otherwise.
3.Dependencies on other teams
Dependencies are always a truth and cost of doing business in my opinion. There are some really cool things we can do to get rid of them, but in the meantime we need to shoot for the most capable team with the fewest dependencies on other teams that we can. Capability modeling can be a life-raft to help with this. Structuring around your existing capabilities and enabling the teams by putting what they need to take care of those capabilities is critical to predictability. Dependencies still need to be managed, but not as much if we are smart about how we staff the team to enable them and figure out capability ownership by the team.
Stable Teams are a non-negotiable part of a predictable system. Sure, their are outliers, but by and large, stable teams are one of the biggest ways you can help yourself and your organization. If you can’t figure out how to do it or are not empowered, get help. And remember, this isn’t just about Scrum teams, it’s about teams.
A design pattern is a re-usable form of a solution to a design problem, given a context. The idea was introduced by the architect Christopher Alexander  and has been adapted for various other disciplines, most notably computer science and software development. If you come from the development side of the house, you should be familiar with patterns. Back in the 90’s a bunch of really smart dudes known as the Gang of Four (GoF), inspired by Alexander, published one of the all-time great software engineering books “Design Patterns – Elements of Reusable Object-Oriented Software”. This book ignited the concept of design patterns in software development. Authored by Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides, it has been influential to the field of software engineering and is regarded as an important source for object-oriented design theory and practice. More than 500,000 copies have been sold in English and in 13 other languages.
Scrum patterns, like design patterns, are proven solutions to repeatable problems, given a particular context.
In similar vein, many of those pattern practitioners from the glory days of OO like James Coplien, Jeff Sutherland, etc. decided to form a Scrum Patterns group known as ScrumPLoP to do for the Scrum industry what the GoF did for software engineering. Their mission, also inspired by Alexander, is to build a body of pattern literature which captures the successful practices of Scrum. Scrum is a context-sensitive framework. It doesn’t tell you what to do. It is not a method. Rather it provides a scaffold to explore and try many different techniques, including the application of patterns. Scrum patterns, like design patterns, are proven solutions to repeatable problems, given a particular context. ScrumPLoP (www.scrumplop.org) is the resource for the library of Scrum patterns. There on the home page you will find a quick synopsis of a few of the more popular and useful patterns, authored by Jeff Sutherland – Stable Team, Yesterday’s Weather, Daily Clean Code, Scrumming the Scrum, etc.
 Alexander, Christopher (1977). A Pattern Language: Towns, Buildings, Construction. Oxford University Press. ISBN 0-19-501919-9.
The first Agile mindset shift is that you should not define an MVP upfront in an Agile world. Defining an MVP upfront is akin to big-up-front planning. You can certainly hypothesize what the minimal set of features might be, but you must have a mindset and practices that have you validate your assumptions and hypothesis. You can start with a vision or general idea of what might be minimal and valuable to the customer but the moment you attempt to succinctly define the set of features, you are not really following Agile and more egregious, you are doing a disservice to your customer.The second Agile mindset shift is that customer feedback is key to evolving the MVP. If you want your MVP to align closely to customer value, you must include continuous customer feedback loops when working on an MVP. These can take the form of customer demos or hands-on sessions. Customer feedback can start as early as when you are hypothesizing what is an MVP and must be part of evolving the MVP to gain a strong inspect and adapt mindset with the inspect coming from the customer. Eric Reis writes that an MVP “allows a team to collect the maximum amount of validated learning about customers with the least effort.” Customer feedback is the cornerstone to validated learning. So who really determines what is the MVP? If you think the answer is you, your management, or your team, then maybe its time to Reduce your certainty and Ready your mind with the Agile mindset, discovery mindset, and Feedback loops. The right answer is the customer determines what is the MVP in Agile. The more closely you align with customers throughout the effort, the more likely you will have an MVP that is considered valuable to the customer. -->
- Acting as a Leader
- Being a developer
- Having a systems focus
- Thinking like an entrepreneur
- Balancing strategic with tactical thinking
- Communicating well
Good software architects understand that their role as a leader is not necessarily telling developers what to do. Rather, good architects act like a guide, shepherding a team of developers towards the same technical vision drawing upon leadership skills such as story-telling, influencing, navigating conflict and building trust with individuals to turn their architectural vision into reality.
A good leader, and thus, a good architect, will listen carefully to the opinions of each contributor, fine-tuning their vision with feedback from the team. This leads well onto the next point.Being a developer
Making good architectural choices is a function of balancing an ideal target architectural state with the current state of a software system. As an example, there is no sense in adding a document database to a system if the problem domain is better suited for a relational database, even if that’s boring. An architect may feel tempted to impose technologies or architectural choices without considering the fit for the problem space – AKA behaviours of the “ivory tower architect.”
The best way an architect can mitigate this is by spending time with developers and time in the code. Understanding how the system has been built up, and the constraints of the system as it stands today will give the architect more information about the right choices for today’s environment.Having a systems focus
Seasoned developers know that code is only one aspect to working software. To make code run, a seasoned developer understands there are other important quality attributes necessary for code to run well in its production environment. They consider aspects like deployment processes, automated testing, performance, security, and supportability. Where developers may approach these quality attributes ad hoc, an architect will focus on understanding not just the code but also the quality attributes necessary to meet the many needs of different stakeholders such as support, security, and operations staff.
The good architect focuses on finding solutions that can satisfy as many of these different stakeholder needs instead of choosing a tool or approach optimised for the preferences or style of a single contributor.Thinking like an entrepreneur
All technology choices have costs and benefits, and a good architect will consider new technology choices from both perspectives. Successful entrepreneurs are willing to take risks, but seek ways to learn quickly and fail fast. Architects can approach technology choices in a similar way, seeking real-world information about short- and long-term costs and the likely benefits they will realise.
A good example is when the architect avoids committing to a new tool based on reading a new article, or having heard about it at a conference. Instead they seek to understand how relevant the tool is in their environment by running an architectural spike to gather more information. They don’t pick a tool based on how good the sales pitch is, but what value it offers, given what they need for their system. They also look for the hidden costs of tools such as how well is a tool supported (e.g. level of documentation, community adoption), how much lock-in the tool brings or the extra risks it introduces over the long-term.Balancing strategic with tactical thinking
A lot of teams build their software reactively with individual developers choosing tools and technologies that they are most comfortable with, or have the most experience with.
The good architect keeps an eye out for what newer technologies, tools or approaches might be useful but does not necessarily draw upon them immediately. Technology adoption requires a considered approach looking at a long-term horizon. Architects will seek for a good balance between agility (allowing the team to move fast) and alignment (keeping enough consistency) at both a team and organisational level.
An exercise like the Build your own Tech Radar is a useful tool to explore technologies with strategy in mind.Communicating well
Architects know that effective communication is a key skill for building trust and influencing people outside of the team. They know that different groups of people use different vocabulary and that using the technical terms and descriptions with business people makes communication more difficult. Instead of talking about patterns, tools and programming concepts, the architect uses words their audience will be familiar with. Communicating technical choices to business people with words like risk, return, costs, and benefits will serve an architect better than the words they use with their development team.
An architect also realises that communicating within the team is just as important as outside, and will use diagrams and group discussions to establish and refine the technical vision, and use a written log like an Architectural Decision Log or a wiki to provide a historical trail for future generations.Conclusion
Doing the job of a well-rounded architect is not easy. There are so many elements to focus us, each drawing upon many skills that a developer often doesn’t focus on practicing. What is most important is not necessarily the ability an architect has, but that they have enough expertise in each of these different areas to be effective. An architect who is skillful in only one of these six areas described above will not be as effective as an architect who has a good level of expertise in all of them.