Introducing SAFe to people that are unfamiliar with it can sometimes seem like a daunting task. People build really big systems with SAFe, so SAFe is not a trivial framework. As part of our efforts to make SAFe more accessible (for one such example, see the blog post on Essential SAFe), we’ve just released a short, informal five-minute video, which gives a brief overview of SAFe and how it works. You can find it here.
SPCs have used previous versions of the video in their Leading SAFe or SAFe for Teams class. It’s also a handy, short introduction for anyone new to SAFe. It can also be used to help garner the interest needed to attract people to a session based on SAFe Foundations, SAFe in 8 Pictures, or even to a Leading SAFe class.
We hope you find it useful,
A few years ago I starting playing around with a book concept that described several personal and professional leadership methods and habits I had developed over my three decade career. I collected ideas, supporting information, and would occasionally – often on long plane trips – take a stab at writing a section or two. I even put those up on LeanPub for folks to review and comment.
For many reasons I never made much headway. There was always something a bit more pressing, or seemingly more manageable, than tackling that behemoth of a project. I enjoy writing, and I felt I had something important to share, but it was never THE priority. In the meantime the project occupied valuable space in my brain. As I get older I’m realizing just how valuable that space is.
Then, last fall at the Lean Accounting Summit, I was approached by an attendee who introduced himself and immediately asked when I was going to finish the book. He knew from my blog and LeanPub that I had been working on it, and he said the story so far had really helped him improve his own leadership style. I decided it was time to either put up or shut up (the polite version of the phrase), and one way or another resolve the project and get it out of my head.
I put up. I sequestered myself on a tiny island for two weeks in December and finished the writing. That draft went through several rounds of brutal editing by a professional copy editor, then text and graphic design. Several colleagues provided very valuable reviews, and Matthew May was kind enough to write a foreword. Todd Clarke did a great “visual one pager” summary.
A week ago I received the final proof, and yesterday the book went live on Amazon. Kindle and iBook versions are just a few days away.
Receiving that final proof felt incredibly good. It is done and I’m very happy with how it turned out. I’m sure I’ll think of improvements over time, but for now the project is complete, and it is no longer consuming space in my head.
The book is organized into eight parts, each with a different purpose:
- Fundamentals – A quick history lesson and exploration of the basics of Lean and Zen.
- Reconnect – Before doing anything, a leader has to be in touch with her or his inner self.
- Create – Methods to improve personal productivity to prepare for the work that is coming.
- Lead – How to engage and lead your team as you begin the improvement journey.
- Clarify – Clarifying what you and your organization are about, defining the current state and the desired future state, and creating a plan.
- Simplify – Using your new plan, you can take the first step and simplify your operation within the context of that plan.
- Improve – Methods to identify and execute improvement projects within the context of your plan.
- Grow – Within ongoing improvement projects in place, it is time to stretch yourself and your organization even further.
I’ve been humbled by some of the initial reviews:
I have long felt that Lean thinking and mindfulness are the two most important breakthroughs in recent years to help us sort out increasingly chaotic lives. Practicing Lean thinking is a clear path to professional success in hypercompetitive markets just as practicing mindfulness is the way to wellbeing in adverse conditions. It also turns out that both build on each other, which is what Kevin masterfully demonstrates in this frank, well-written and deeply insightful account of his own journey. The Simple Leader is simply a fantastic read!
– Michael Ballé, author of Lead With Respect: A Novel of Lean Practice
Leadership is at the core of any organization, and transforming leadership mindsets and practices is at the core of Lean management. Meyer is a rare author who’s not only studied Lean deeply but has also served as CEO. The Simple Leader is chock full of essential leadership practices that are key to organizational transformation and outstanding business performance alike.
– Karen Martin, author of The Outstanding Organization: Generate Business Results by Eliminating Chaos and Building the Foundation for Everyday Excellence
If you’re thinking, “Not another book on leadership,” then you’re in luck. This is not the same old vacuous pablum that so many consultants peddle, or the same sophomoric insights that Zen fanboys wax lyrical over. Kevin’s experience as a business CEO, a student of Lean, and a practitioner of Zen combine to produce a uniquely insightful, wonderfully practical guide to management that will be useful to anyone seeking to be a better leader. I defy anyone to read this book and not learn something immediately useful, applicable, and valuable.
– Daniel Markovitz, author of Building the Fit Organization: Six Core Principles for Making Your Company Stronger, Faster, and More Competitive
I’ve always been impressed by Kevin’s dedication to simplicity. This book collects his insights from a lifetime of experiences, travel, reading, work and reflection into a simple and practical book. Open up the table of contents and place your finger down on any topic, and I guarantee that you will find practical hints and insights in this book to help you improve. Take a moment to invest in yourself by reading and reflecting on how to reduce complexity in your life and work.
– Jon Miller,author of Creating a Kaizen Culture: Align the Organization, Achieve Breakthrough Results, and Sustain the Gains
Lean and Agile thinking are founded in a deep ‘Respect for People’, experiential learning, and a realization that continuous improvement and innovation come from direct observation at the Gemba. In our increasingly complex, distracted and over stimulated world, presence and mindfulness, captured in the Zen instruction to ‘Pay Attention!’, are increasingly relevant. This book may not only change how you lead, but also how you live.
– Steve Bell, author of Run Grow Transform: Integrating Business and Lean IT
One might say then that Simple, Leader, Lean, and Zen are inherently conflicted, at odds with one another, and that reconciling them would entail a rather Herculean act of creativity. But creativity is the act of bringing something new into existence, the defining quality of which entails connections between seemingly disparate ideas. This is the beauty of The Simple Leader. This is power of the Lean-Zen nexus.
– Matthew May, author of Winning the Brain Game: Fixing the 7 Fatal Flaws of Thinking
Effective personal leadership, requiring conscious individual reflection, is a critical foundation for effective professional leadership. Building on his deep hands-on experience with core Lean and Zen concepts, principles and practices, Kevin Meyer provides the reader with concrete advice and examples necessary to become that outstanding leader. In The Simple Leader Kevin demonstrates how each of us can gain leadership clarity by reducing leadership strategy and processes down to a handful of important truths. The Simple Leader is a short read that delivers with impact. Read this book.
– Adam Zak, co-author of Simple Excellence: Organizing and Aligning the Management Team in a Lean Transformation
The simple leader is not simple at all! The simple leader is the one who has tamed complexity with the notion that simplicity is true elegance. The irony is that the more successful we all become, the more we are enveloped by complexity and reject the intelligence of simplicity. The idea that Kevin could succeed in the business world and understand that success is rooted in simplicity is profound. The Simple Leader is a fantastic story of how Kevin has done this and I was taken with his honesty and brilliance.
– Paul Akers, author of Lean Health: Aging in Reverse
Thanks to all of you who have supported me on this journey!
I just posted the dates for the next Practical Product Ownership workshop: Deliver What Your Customers Need. It starts Aug 23, 2016.
You need this workshop if:
- You are having trouble doing everything in your PO role, you might be trying to do too much. See Product Manager, Product Owner, Business Analyst?
- You are having trouble deciding how to organize your backlog, roadmap, and everything.
- How to value the items you do organize. We discuss Cost of Delay and seven other possibilities to rank the items.
- How to help people articulate the problems they want the team to solve, not the solutions.
- And much, much more.
We meet twice a week for six weeks. Our first meeting is a 90-minute teaching call, where I teach and you ask questions. We meet later that week for a 60-minute coaching call, where you bring your problems, concerns, and challenges.
I estimate you will have about 60-90 minutes of homework every week. Any other questions? Email me.
By LibertyGroup25 (Own work)
Henry Ford pioneered many of the ideas that are now commonplace in business, including ideas used in Design Thinking. He has been quoted as saying "If you ask people what they want, it would be a faster horse." This hits on the design thinking principle of divergence. You need to understand what problem you are solving before coming up with a solution. Henry Ford wasn't solving a problem around horses, he was solving a transportation problem.
I was in a design thinking workshop and we did an exercise where first we were asked to draw a door bell. Then we were given a problem in a different framing, we were asked to draw a way to know if someone was at the door. The second set of drawings were much different. A doorbell would have worked, but by reframing the question, many other solutions came out.
Another Henry Ford quote is "you can have any color, as long as it's black." On the surface, this might not sound very customer friendly, However, this response was due to the solution to another problem. When he was developing the production line for the Model T, he was challenged in the painting step. He found all paint colors took to long to dry, except black. By only offering black, he was actually fixing a bottle knock in his process...applying the theory of constraints as it were.
Next time you're working on a solution to a problem, spend a few minutes and think about the framing of the question. Can you change the question in order to expand you possible solutions?
Some recent discussion in the WatchMeCode slack spawned a bit of research into creating custom errors through factory methods, while keeping the stack trace for those errors clean, in Node.js
After a bit of digging, I found a good solution using Node’s Error.captureStackTrace method, and recorded a quick screencast to highlight it’s use.The Screencast The Sample Code
If you’d like to run the sample code that I showed in this screencast, you can grab it from this gist.Additional Resources
And if you would like to read up on errors further, check out these additional resources:
Op 21 juni geef ik de workshop Valuable Agile Retrospectives in Utrecht. In deze succesvolle workshop leer je de waarom, wat en hoe van retrospectives en oefen je in teams met diverse manieren om retrospectives uit te voeren. Continue reading →
- Organizational Design Without Empathy Won’t Work (Sam Spurlin)
- 0 Bugs Policy (Gal Zellermayer)
- How a Worker-Owned Tech Startup Found Investors—and Kept Its Values (Nathan Schneider)
- Embracing Agile (Harvard Business Review)
- Continuous Deployment at Instagram (Michael Gorven)
- Where the hell are all the great senior software developers and hands-on engineering directors? (Obie)
- The Ratio of Women Speakers in Tech (Phil Sturgeon)
- Giving better code reviews (Joel Kemp)
Image attribution: Freepik
- Sponsored: 64% off Code Black Drone with HD Camera
Our #1 Best-Selling Drone--Meet the Dark Night of the Sky!
I believe there are the two primary success factors in creating a thriving business: a culture where customers matter and employees matter. I’m not talking about the lip service that is prevalent today. In some cases, we see quite the opposite, where employees are disenfranchised and customers are rarely engaged. Instead, the goal is to have a culture and practices in place that truly gain the benefits of engaging with customers and employees. Through the customer and employee, a company draws their power within an agile culture and, I contend, within any thriving company. When you have a riveting focus on the customer and you believe that an engaged customer matters, then you have the basis for a relationship where you can truly understand what the customer wants. When you have a sharp focus on employees and provide them the space to make decisions and own their work, then you will begin to understand the value an engaged employee base can provide.
If the values are sincerely translated to organizational objectives and agile approaches are applied, then it can act as a differentiator between the success of your organization compared to the success of other organizations. Of course, every company likes to say that employees and customers matter, but are their objectives and actions really aligned with these values? Upon closer inspection, the values should translate into objectives focusing on customer engagement and employee engagement.
- Customer engagement focuses on establishing meaningful and honest customer relationships with the goal of initiating continuous customer feedback to truly identify what is valuable to the customer. This includes establishing all of the activities involved in a Customer Feedback Vision.
- Employee engagement focuses on empowering employees so they can self-organize into teams and can own and be a part of the decision-making process at their own level. When employees have ownership, they have more passion in their work. When they have more passion, they give 110%.
Then we add the “secret ingredient” of applying a continuous and adaptive approach (a.k.a. agile culture, processes, methods, practices, and techniques). If done properly with the ability to adapt, this can lead to an increase in customer sales and an increase in team productivity. This finally leads to your incentive, which is an increase in company profits.
Now is time to take a moment. Are employees disenfranchised or fully engaged? Are customers rarely engaged or is their feedback continuously engaged? Is Agile just a trend that others should do or are you serious about Agile and the culture shift it requires? Keep in mind, the combination of customer and employee engagement within an Agile context isn’t just a good idea, it is great for business.
PS - to read more about the importance of customers and employees, consider reading Chapter 3 of the book entitled Being Agile.
I first heard of SATURN via social media through Michael Keeling, an IBM employee who spoke at XP2009 many years ago. Sam Newman spoke last year about Microservices. Although the conference has a Call For Papers (CFP) each year, they also had a small number of invited speakers and Michael organised for me to go along to talk about Evolutionary Architecture.
SATURN is a conference organised by the SEI (Software Engineering Institute). SEI are probably most well known for CMM, although there is now another institute responsible for it. The conference has been running since 2005 and has a long history of focusing on architectural concerns.Architecting the Unknown keynote by Grady Booch (@Grady_Booch) What I really liked about the conference
I believe that one of SATURN’s greatest strengths is a focus on architectural thinking, through the application of the latest tools. Unlike some other conferences, I felt like the programme tried to assemble a good collection of experience reports and presentations that emphasised the architectural principles, rather than focusing on the current tools.
Although this may be less popular for people wanting to learn how to use a specific tool, I feel this emphasis is much more valuable and the lessons longer lasting.
What I also really enjoyed about the conference was the relatively small size which was just over 200 participants from various parts of the world. Having a good location, and small size allowed for some better quality conversations both with other speakers and attendees. One good example of the conference facilitating this, was an office hours session for attendees to easily ask questions of speakers. I shared by office hours with Eoin Woods (author of Software Systems Architecture) and Grady Booch (IBM Fellow, One of the Three Amigos who were best known for developing the Unified Modeling Language).Conference dinner at a baseball game for SATURN 2016
During the conference I spoke with many people carrying various Architect titles. Interestingly many came from many larger organisations and government agencies, which shouldn’t have been any surprise given the history of the conference. I remember meeting and speaking with one particular Enterprise Architect (EA), who seemed to be one of the most pragmatic EAs I’d met, who was trying at all costs to stop his board randomly signing large contracts with product vendors like Oracle and IBM without the proper diligence about understanding what they were actually building.
At the same time, I met a number of architects struggling to help their organisations see the value of architecture and the role of the architect.My talk
I spoke after Booch’s initial keynote, “Architecting for the Unknown” which lead really well onto the topic I was speaking on, “Evolutionary Architecture“. I had a packed room as was a topic that resonated with people. At one point the conference organised brought more chairs into the room and there was still only standing room for the 90 minute talk! I had some great questions and conversations throughout and found out later that I won the award for the best conference talk in the “Architecture in Practice” category!SATURN Evolutionary Architecture talk audience
I’d definitely recommend attending SATURN if you’re interested in focused on building architectural thinking and an opportunity to connect with architects across the industry. The size is great for conversations, sharing experiences and with next year’s scheduled for Colorado will be really interesting too.Final thanks
I’d like to thank the organising group calling out Michele Falce (Technical Event Coordinator), Bill Pollak (General Chair), Jørn Ølmheim and Amine Chigani (Technial Co-Chairs) who did a great job putting together a fantastic conference, John Klein for hosting Office Hours, and Michael Keeling for organising an invite for me.
[[ This is a content summary only. Visit my website for full links, other content, and more! ]]
- Sponsored: 64% off Code Black Drone with HD Camera
Our #1 Best-Selling Drone--Meet the Dark Night of the Sky!
My name is Andy Hoover and I manage our Customer Support operations here at LeanKit. I spend...
The post How Integrating Zendesk with LeanKit Changed Customer Support appeared first on Blog | LeanKit.
There are a lot of great aspects of software development, including writing code, solving problems, and generally working with cool technology and toys.
But of all the things that I do as a developer, there is 1 thing in particular that I absolutely love doing. And that one thing? It’s not solving problems, surprisingly (though this is probably a close 2nd).
At this year’s Global Scrum Gathering in Orlando, SolutionsIQ President John Rudd and I presented on the topic of Agile portfolio management. During our presentation, Andreas Schliep (long time Certified Scrum Trainer, Agilist, and hilariously dry-witted guy based in Germany) tweeted,
“Brent Barton and John Rudd gave the term business agility a useful meaning. Think portfolio.”What is Business Agility?
Prior to the presentation, Andreas told me how concerned he was with the term “business agility” because it lacks meaning and can water down a company’s ability to derive the real benefits from being “Agile”. Luckily for Andreas and many people attending our session who were uncertain about what exactly business agility is, thinking about it from a portfolio perspective provided a pragmatic way for business to support a modern organization. Now I’d like to share here what we shared to participants that day.
Simply put, business agility means leveraging iterative delivery capability and actively managing organizational investments. The bottom line is that, if we do not align our portfolio practices to leverage what Agile has to offer, we miss out on opportunities to maximize returns and adjust plans.
The rest of this blog is dedicated to “thinking portfolio” and one of its most important components: Return on Team.What is Return on Team?
Return on Team aligns today’s needs for planning and budgeting. It is a better and simpler way to manage a portfolio. In many ways, small (<10 people), dedicated, persistent, cross-functional, empowered, self-organizing teams are at the core of Agile. This structure is best for knowledge workers who solve today’s complex problems like software solutions. Rather than dissolving teams (in particular high-performance teams) and incurring the unnecessary overhead of reintegrating individuals, we can think of these teams as assets. Further, establish these dedicated and persistent teams as enduring corporate assets. Then like tracking return on an asset, we plan and track Return on Team.
Consider an airplane. Notice that in the previous sentence, I said “an airplane” indicating that it is a concise unit by itself. But you could, as engineers may, consider the entire vessel a collection of many integrated parts that operate in concert to produce the value that airline customers seek (i.e., flying from point A to point B). It seems ridiculous to think about a single airplane as a bunch of constituent parts–and yet this is precisely how we think about individual team members on a team. The team is an airplane: the individual parts (team members) collaborate and coordinate to deliver the value that end-users seek, whether that’s software or something else. When you have a high-performing team, the last thing you want is to break them up just when they’ve achieved velocity–probably for the same reason you wouldn’t dismantle an airplane midflight. But just like you can move an airplane from one hangar to another (even when it isn’t carrying passengers), you can reassign a team from one initiative to another one. Your teams are enduring corporate assets, like a fleet of airplanes. Once they’ve hit their stride and produced consistent value quickly, you can actually plan and track accordingly. That is the combined power of Return on Team and active (Agile) portfolio management.
The team is an airplane: the individual parts (team members) collaborate and coordinate to deliver the value that end-users seek.
Return on Team allows planners to match supply (team capacity) to demand in a data-driven manner. This simplifies the process by an order of magnitude and prevents us from accidentally pulling people off one team only to re-form another and incur transition costs. Also, we have better data as a result. When a system does not change, history is the best indicator of future performance. By keeping teams persistent, we can use historical data to plan more realistically.How Do You Measure Return on Team?
There are two ways to measure Return on Team: trend and performance against plan. Since persistent and dedicated teams focus on a common delivery stream, relative contribution to a corporate endeavor is easy to measure. Also, teams tend to get better at estimating over time. Costs are more stable, so they can be calculated simply. For example: one team costs $25,000 per week. Thus, if a piece of work is budgeted at $300,000, the team has 12 weeks to finish the work before the budget is exhausted. If it is a stable team, we can use previous trends to calibrate likelihood of a good outcome very early. Regardless how an organization calculates benefits (and expected benefits), the denominator of the basic benefit/cost ratio is very simple and maps into team’s work without friction. The result is greater predictability and thus reduced risk, with the ability to move away from investments that are not showing benefit.
Finally, most of the work teams do is based on investments much longer term than a year, except when the organization is in search of new potential long term investments. Thus, in order to support short term business commitments against long-term investments, we need to become good at developing short-term initiatives (often about a quarter in length) so we can course correct without as much gnashing of teeth. These short term-initiatives can be estimated in comparable team units which we call a team iteration. Now, we have units of supply that we can match to demand with short-term outcomes derived from long-term commitments. From this, we can base our decisions from the perspective of Return on Team.Summary
In review, persistent and dedicated teams, as corporate enduring assets, delivering increments of customer value every iteration cycle with a predictability that portfolio managers can use to plan short-term initiatives that drive toward long-term investments–that is the ultimate goal of business agility. The Agile business can plan with a greater level of confidence and predictability and reduced level of risk.
To learn more about Return on Team and business agility, check out Brent’s webinar “Agile Portfolio Management: Adapting to Changing Priorities”!Watch Now
One of the easy mistakes in building a REST API is trying to take your rows out of the database and expose them directly as JSON. Such technology exists, where you can directly expose stored procedures as SOAP web services, or protocols like OData. You can also just expose your entities directly as JSON through a web service, but you’re missing out on some big distinctions of resources and representations.
So first, what is a resource? That’s actually quite easy – a resource is anything with a URL. The converse is not true, a URL is not a resource, mainly because the URL is the Uniform Resource Locator. If you can locate a resource, then it exists. And Fielding was pleased.
The representation is a bit different – it describes the current state of the resource (when requested).
So what does this have to do with entities? Well, nothing. There is no relationship between entities and resources. And that’s a good thing, it’s exactly how the web works.
When you navigate to a web page, an online retailer, and look at a list of products, what is the resource? From the client’s perspective, we don’t know. We have no idea of the implementation details of the resource, other than a way to locate it and request a representation. Again, Fielding was pleased, as this decoupled us from the implementation details of the resource.
So where does this leave us when building APIs?A decoupled API
In APIs that serve the client according to their needs, the resource often includes details from many different data sources, combined together to build a representation to the end user. A REST API builds all this together:
In hypermedia APIs I build, the resource state combines multiple entities together from one or more data sources into the state of the resource. This plus links, forms a queries makes a “resource”, though it’s still a bit more abstract than that. Finally I build out the representation, perhaps JSON API, HAL, Siren etc.
If I made my entities equivalent to resources, I’m likely forcing clients to make many round trips to all the entities they need, but even more, I’m directly exposing the implementation details of my service to the world. Perhaps I’m removing some fields here and there, but in reality this is only one step above handing clients a connection string to my database. Sure, it’s easy and convenient to expose entities directly as resources and representations, but there’s some serious coupling that comes with that choice that you must accept.
In my experience, if I approach the API design strictly from the client perspective, on what they’re trying to achieve and why, it’s actually quite rare that I arrive at an API design that is simply database CRUD exposed as HTTP. And Fielding was pleased, as this design most closely matches the everyday use of the web. Makes sense. That’s what REST is about – a set of architectural constraints describing basically, the web.
Post Footer automatically generated by Add Post Footer Plugin for wordpress.