(in Hinduism and Buddhism) a spiritual teacher, especially one who imparts initiation.
synonyms: teacher, tutor, sage, mentor, leader, master, expert, authority, pundit
Go to Twitter and search guru. You’re going to find it applied to anything from Agile to Marketing to Love. To be clear, I wasn’t originally looking for a guru. I just noticed it in someone’s profile and was curious who else thought they were one.
After doing some twitter searches, it’s amazing how many people think they are a guru. Seller? Yes. Teacher? Maybe. Master? I think not.
— Derek Huether (@derekhuether) January 4, 2016
My Twitter post on the topic resulted in an enjoyable conversation with Gitte Klitgaard @NativeWired, who describes herself as an Agile addict, hippie and a pirate, Rob Myers @agilecoach, who describes himself as helping people craft worthwhile products and enjoy their careers, and Mike Kaufman @mkaufman811, who describes himself as a ScrumMaster, Agile Evangelist, and Dad.
The four of us participating in the conversation kept it civil and I believe we all got value from it. After our exchange, I would have to say, I’d be quicker to listen to what they had to say than I ever would any of those claiming to be gurus in our space.
Here is a link to part of the conversation.
The question is,
are self-professed gurus in your domain selling, teaching, or actual masters?
I see guru as one of those terms that is grossly overused. If someone said to me something like “Dude, you’re a guru.” I would be flattered by the comment. I just think I’m driven, obsessive, and passionate about improving things and engaging people. But a guru? No.Thoughts from the community
Do you think the term is overused in the Agile space? Is it overused in other domains? Do you think you’re a guru and grossly underappreciated? I want to know what you think. Add a comment.
I'm going to be at the new Agile Alliance Technical Conference taking place April 7-9 in Raleigh! I'll be presenting a more-detailed version of my "Agile Engineering for the Web" talk:Agile Engineering for the Web
Conference registrations aren't open yet, but I'll update this calendar entry once they are.
One concept had to do with constraints. Anyone that has worked much on projects know that constraints are a big part of it. He talks about three aspects of constraint; feasibility, desirability, and viability.
Feasibility is looking at whether or not something can be done in the near future.
Viability is looking at whether or not it's sustainable from a business model perspective.
Finally, desirability of course is will it be something that people want. In design thinking you want to take into account all three of these aspects as you're working on a project.
As I think back to projects that I have had that have been either successful or not successful, I can see how all of these play into a project's success or failure.
On an actual project, we can test for feasibility by doing something like a spike, a short test to prove out if the idea will work.
Viability may be a bit harder to show on a project. It will take other supporting input such as market research to prove the approach is a sustainable business model. This is probably best done before you go to far in the project.
I think there's a very strong tie between desirability and how agile projects work. It's that whole idea of working closely with your users to truly understand their needs.
I've seen other ties between design thinking and the agile approach. I'll have more to say on the future blog post.
It is a bit crazy to think we are already in 2016 but before we get too far into the new year here is a quick review of what has been happening at Illustrated Agile in 2015.
Thanks to all of the new email subscribers to the blog. It’s been a record year for the number of subscribers this past year and your loyalty and encouragement is appreciated.
For the next couple of weeks, new subscribers to Illustrated Agile will receive a digital copy of my book “Becoming a Catalyst: Scrum Master Edition” for free! I have also included a companion coaching worksheet to download as well so you don’t want to miss out. Just subscribe using the form in the upper right of this page and you will receive the links.
My Favorite Blog Post to Write in 2015
In looking back at the 19 posts from 2015, selecting a favorite means looking back at the easiest to write. Hands down, “What Agile Feels Like” flowed naturally and if memory serves took very little time to write.
“What Agile Feels Like” was the output of conversations with people not very satisfied with the results of their Agile transformation. Many think they have mastered the mechanics of Agile but something still doesn’t feel right. Typically, this happens when the mechanics of Agile clash with a culture still aligned with legacy behaviors and systems. This post explains what I feel and sense from organizations beginning to thrive in an Agile environment and are willing to break free from the past.The 19 Blog Post Written in 2015
Scrum Master Resolutions (2016 Edition)
In my opinion, the role of Scrum Master will need to evolve to stay relevant. Make 2016 the year for you to begin the journey.
5 Questions to Ask Before Hiring or Promoting an Agile Leader
Shaping a positive leadership legacy starts with who you hire and promote. Ask yourself these questions before doing either.
A Scrum Master Job Description
How do you know if the Scrum Master you are looking to hire will be the right fit for your Agile journey. Here is a Scrum Master Job Description template to use for your job postings.
So Different…Yet Very Much the Same
A summary of my time coaching in South Africa and discovering no matter where you are in the world we are dealing with many of the same things.
What Agile Feels Like
If you can’t feel an Agile transformation you can bet it isn’t happening. I’m not saying everyday is a party but the energy being emitted should be palpable.
How to Capture Scrum Master Feedback
Integrating feedback from an Agile team into existing performance management systems can be tricky. Here are a few thoughts on how to capture feedback for your Scrum Masters.
The Anatomy of an Impediment
Most Scrum Masters would say removing impediments are a part of their responsibilities. But what is an impediment anyway?
Is “Protecting the Team” the Right Thing?
A Scrum Master often thinks they need to protect the team from outside distractions. Are they doing more harm than good?
Becoming a Radiating Team
A sure sign a team is not radiating information is when someone requests a status report. Transparency should be a natural part of the DNA of an agile team.
Preparing People for Organizational Change
Change is always a personal journey and everyone’s experience will always be different. With this post, we talk about how we can prepare people for change.
The Deliberate Practice of Being Agile
Can we deliberately and intentionally practice becoming a team? Can we find ways to design the improvement of teams and agility into everyday life? I think we can.
Creating an Environment of Confidence
Many organizations are struggling with a demoralized and weary workforce. Here are a couple of ideas for helping people find, build, gain, and keep confidence.
The Elephant in the Room (A Performance Review Conundrum)
In response to an Ask Anything question from a reader, we dig into how to handle a challenging performance review issue.
An Important But Uncooperative Team Member
It only takes one. Every so often, we bump up against an important team member who creates challenges to creating a healthy team environment. This Ask Anything question provides a few options with how to handle it.
8 Rituals of Amazing Scrum Masters
After coaching and observing many Scrum Masters, here are a few of the rituals of the ones making the biggest impact within their organization.
5 Common Pitfalls for a Product Owner
The Product Owner is a linchpin role for an Agile team. Here are a few thoughts on how to keep them healthy, engaged and productive.
3 Things to Observe in a Sprint Review
Just about everything you need to know about how an Agile team is performing can be witnessed in the Sprint Review session. Here’s what to look for.
2015 New Years Resolutions for Scrum Masters
Slow down and find time for yourself, letting going of control, and investing in experiences. These resolutions for 2015 still apply today.
If you’ve looked at the Scaled Agile Framework® (SAFe®) before and determined it wasn’t adequate for your large-scale development, look again.
The fourth version of the Scaled Agile Framework just hit the streets and includes major enhancements that support large-scale software and systems. For highlights, check out our blog, “10 Things You Need to Know About SAFe 4.0."
Over the past four years, we’ve watched SAFe grow from a nascent framework with its usual skeptics (see this post from a converted one) to a recognized standard. This past year in particular, we’ve seen a surge of interest in SAFe from organizations determined to gain business benefits that team-level agile adoption alone couldn’t provide. Don’t get me wrong, good agile teams—those that don’t fall into common traps—are absolutely necessary; they’re just not sufficient in enterprises that are trying to survive amidst fierce competition.
SAFe 4.0 takes a quantum leap to address the complex challenges of developing software, systems and even systems of systems. In our experiences working with large-scale customers, previous SAFe releases really helped kick off scaling agile initiatives. But once you got past your first two value streams—adequately referred to as kidneys in SAFe—you were on your own to extend the framework. In our Portfolio Agility write-ups last year, we documented the need to go beyond the kidneys by taking a demand-and-supply view of large systems.
Thankfully, 4.0 got rid of the kidney limitation. It added extra brain, including more value at the Portfolio level as well as a brand new and optional Value Stream level for large-scale development.
At the Portfolio level, the addition of explicit practices for managing CapEx and OpEx matches the growing need to include financial concerns in agile transformations. As software enables business strategies, software expenses become a material concern to accounting. But because the Generally Accepted Accounting Practices are still worded for waterfall development, over-expensing agile software happens often. Finance professionals partnering with agile development leaders need new mental models to adapt their accounting practices for agile development—something we provide through our Agile Accounting and Capitalization consulting service.
We validated the new Value Stream level concepts in our large customer engagements. Decoupling business value streams from development value streams is essential to match demand and supply without clubbing the two too prematurely. While working closely with Elekta (see our customer spotlight video and this SAFe case study), we saw this decoupling foster incredible conversations between business and IT.
The strong focus on Kanban systems, including added support for Kanban teams, aligns with what we see as the achilles heel in the software industry—taking on too much work and working on batches that are way too large, ultimately bringing the project highway to a traffic standstill. Kanban boards help you visualize your WiP (the highway) so you can stop starting and start finishing new work. Thank you, Eric Willeke, CA Transformation Consultant extraordinaire for your contribution to the SAFe framework on this topic.
Our fleet of SAFe Program Consultants is anxious to help you use the new 4.0 concepts and share how we’ve seen them work in real-world, large-enterprise settings. These new concepts require an even bigger thinking cap than before, and one of our best SAFe assets is the wide range of experience among our coaches. By selecting CA as your SAFe partner, you don’t just get guidance from one coach; you get the collective expertise of more than 50 SAFe Program Consultants who have actually implemented these concepts in large-scale, distributed environments. How cool is that when you can learn from others’ experiences to boost your success rates?
We’ve bottled up our years of experience in scaling agile into a unique and repeatable approach called Ready > Sync > Go. It combines training, product implementation and Big Room Planning expert facilitation to help you get results from your Program Increment (PI) planning in less than three months.Platform Support for SAFe 4.0
Now let’s look at how CA Agile Central (formerly Rally) features support the new 4.0 concepts.Portfolio Level
One of the most impactful changes in 4.0 is a Portfolio-level refocus on investments and how financial resources are allocated against different strategic goals—further improving the ability to centralize strategy and business value, while decentralizing detailed planning and execution. Now, organizations can effectively form and structure Agile Release Trains (ARTs) at the Value Stream level, while aligning strategy and large efforts across the enterprise. Removing ARTs at the Portfolio level (they’re now at the Value Stream and Program levels) matches the need to clearly articulate business value at the Portfolio level before determining how best to deliver it.
Lean Budgeting: Evolving from project funding to value-stream funding is hard, especially when your company is not fully agile. CA PPM customers who are managing agile and waterfall projects can start practicing Lean budgeting via the CA PPM integration with CA Agile Central. In CA PPM, create an Organizational Breakdown Structure to model ARTs as value stream resource pools. Once Epics are approved for implementation, the integration automatically creates Epics in CA Agile Central for ARTs to focus on the approved Epics.
Thanks to our work with large customers who extended the 3.0 framework to track solution value between Epics and Features, CA Agile Central already supports value stream elements.
Capabilities to track high-level solution behaviors: These collections of Features below an Epic are tracked in the portfolio hierarchy between the Epic level and the Feature level. CA Agile Central uniquely scales by maintaining the data integrity between Epics, Capabilities and Features, so you don’t have to ensure data is tracked adequately.
Value Stream Kanban to track flow of Capabilities: The Portfolio Kanban set for the Capability portfolio item provides specific Kanban states, exit policies and WiP limits that are specific to the Value Stream.
Program execution is the heart—and the legs—of a SAFe implementation. If you can’t deliver on your strategy, it doesn’t matter how good your strategy is. And if you can’t execute, you can’t innovate either. Building a predictable delivery engine is at the crux of scaling agile, so portfolio decisions are based on empirical evidence of delivery. CA Agile Central has strong platform support for PI ceremonies. Releases track the PI timeboxes to plan on cadence, while Milestones track the deployment cadence to deploy anytime.CA Agile Central provides unique capabilities to support all three phases of PI planning
Before PI Planning: Minimize waste at the PI event.
- Capacity Planning: Respect predictability capacity margins. Ensuring product managers focus on elaborating only the features that will fit in a PI is a typical challenge. Our capacity planning functionality acts as a reality check before the PI Planning event, and we’ve extended it to support planning one feature across multiple teams, which helps deliver value to customers, faster.
During PI Planning: Optimize the return on investment for the PI event
- Team Planning: Align stories to their feature context. The Team Planning page, currently in limited beta and available soon in open beta, empowers teams to plan stories that support the PI Features. This is where scaling agile differs from Scrum and where team-level agile tools that only support Scrum fall short in connecting team stories to larger portfolio business goals.
After PI Planning: Track the PI plan during execution.
- Release Tracking displays team plans in the context of program features and surfaces dependencies and risks. Use Release Tracking to assisst with the PI confidence vote and during your steering meetings, to show real-time progress and to spark discussions around priorities, risks and dependencies.
It’s great to see Team Kanban finally recognized as a first-class citizen in the framework. We’ve seen teams dealing with interruptions welcome the Kanban way to track their work, and teams enjoying Scrum find benefits in supplementing Scrum views with Kanban views to shorten lead time and improve value flow.
Team Kanban with classes of services: The Kanban Board app supports the new Team Kanban concept and has swimlanes designed to increase visibility into what matters most to the team.
Communities of Practice (CoP) with inter-team communication: Collaborating across distributed sites and time zones is a way of life in enterprise settings. The Flowdock capability is built for 24x7 communication so teams can get fast answers from their CoP.
CA Agile Central also supports the following concepts that transcend all SAFe levels:
Requirement Model Traceability Support (Epic>Capability>Feature>Story). The Portfolio Hierarchy provides trustworthy rollup reporting by reliably maintaining traceability between the new Capability artifact, its parent Epic and its children Features—without any concerns about data integrity (as each requirement type is its own portfolio item type).
Enablers to track exploration, infrastructure and architecture work. Track Enablers as Stories or Portfolio Items with a boolean custom field to differentiate the Epic/Capability/Feature/Story from enablers. Then, visualize the Enablers work and the non-Enablers (Epic/Capability, Feature/Story) with a Kanban to maintain a good balance of architectural runway vs. customer value delivery.
Scaling agile is no small feat, but you can ease the challenge by selecting a partner that provides you with unmatched expertise from actual SAFe implementations and a scalable platform that supports all the SAFe core values—program execution, alignment, transparency and built-in quality. To learn more about our support for SAFe 4.0, visit our SAFe toolkit page and register here for our “Get Ready for SAFe 4.0” webinar, co-presented by Dean Leffingwell, on February 9 at 12 p.m. MST.
A few posts ago I mentioned that I roughed in some 20 plus articles I intend to write over the next few weeks. By the time this one goes out, I think you’ll have seen two or three of them. It was interesting to take a step back and see where my head has been these past few weeks.
There was a clear pattern emerging.
In any movement… and yes, I see agile as a movement… you have lot’s of different constituencies.
You’ve got consultants with something to sell. You have evangelists interested in advocating their particular point of view. You have thought leaders interested in advancing the state of the art. Each bring their own set of biases and their own unique perspective to the conversation.
(For the record, I fall into all three of these categories in some form or fashion)
As folks consume our collective wisdom on all things agile, many of them are not as well informed, or as well read, or even have the time and inclination to dissect, understand, package, or repackage these ideas to make them work in their organizations.
Many… not ALL of course… are operating from a partial playbook.
I believe the principles behind agile are inarguable. I believe that many of the patterns and practices that make agile work are inarguable. I think agile fails when we implement these principles and patterns and practices in an inappropriate context.
Everything written by anyone that has ever written anything on agile is from their own context, their own point of view, and based on their own experiences. To assert otherwise is nonsense. When we package our agile experience up into a thing, all that context gets lost.
That said, the market demands a simple, pre-packaged solution. It demands a two-day training course. It demands an easy to read one-pager describing the process. The market wants agile to be simple and understandable. Something that can be purchased off the shelf.
The reality is that it’s nuanced. It’s unique to the organization. There are no simple answers.
As I started looking through my notes from the past few weeks, and in all honesty… my last few years of writing… my last few years of company building… and my last few years of consulting… it’s all about discovering language that helps people understand without pretending its easy.
Themes that emerged were around safety, leading change, dealing with resistance, failure modes, and success patterns. My brain is absolutely centered around the fundamental base patterns that work and how to break down barriers to their application in real companies.
My brain is focused on how to package all this stuff up into something that is marketable and meaningful, not necessarily by describing the end state, but by describing how to package all this up into a safe and effective model of iterative and incremental change management.
In other words, what’s the process of transformation. What do the intermediate states look like and how do we get there? There is so much noise in the system… so many competing points of view… how do we cut through the bullshit and get to something that works for us.
Shifting gears, a little…
This morning I woke up to series of blog posts and tweets lamenting the fall of agile. How agile doesn’t work. How we are post agile and that agile has failed. One of my favorite bloggers was debunking the latest agile myth in an attempt to bring some sanity to the conversation.
To some extent, I think we are experiencing a pendulum swing in the industry. On one extreme, we have the waterfall boogeyman, that for the most part has been roundly marginalized in the industry. Still there, but not very popular right now.
On the other extreme, we have a total anarchist view of agile based exclusively on empowering people to decide, telling managers to back off and leave folks alone, but failing to give the people spending the money any assurance they’ll get any value for their dollar spent.
The answer isn’t extreme control over every detail. The answer also isn’t total lack of control over time, cost, and scope constraints that give our investors some reasonable assurance they’ll get something of value for their money. For most companies, the answer’s in the middle.
If you decide to pay attention as I get all this stuff typed out, what you are going to see is an exploration of the thinking tools, the organizational patterns, the failure modes, and processes I think are necessary to really lead change in large enterprises.
I’m not talking about the squishy, feelings related stuff, around change… but the hard… how do you actually do it kind of change. How do you form teams… specifically? How do you create a governance model… specifically? How do you measure stuff… specifically?
I believe there is a bunch of good that can be had by adopting a team-based iterative and incremental approach, out of helping people get clarity around what to build, and helping people understanding what to measure. I also think it’s okay to tell people how to get started.
If that’s too prescriptive to be agile… I’m good with that.
I'm presenting a full-day tutorial on agile engineering and front-end development at Agile India 2016 in Bangalore. This is going to be a code-heavy session with lots of hands-on work. If you liked my Øredev video on this topic and want more detail and a hands-on experience, you should come to this tutorial.Agile Engineering for the Web
I'm keynoting at Agile India 2016 in Bangalore. The topic is large-scale Agile, and it's one I'm particularly eager to present. I've been thinking and working with companies on this topic for many years now. This will be the first time I've presented my battle-tested ideas.Scaling Beyond the Enterprise
The brilliance of early Agile methods was their non-conformity. They rejected conventional wisdom about how software should be created and substituted a new reality: one where collaboration, adaptation, and continuous improvement were more important than rigid processes and plans. At first, many people rejected these innovations, but Agile stood the test of time. Now it's won the day.
When people talk about scaling Agile, they forget those insurrectionary roots. They focus on what's palatable to the "enterprise:" how to make Agile safe, non-threatening, and acceptable--how to make it more conventional and conformist. In doing so, they risk losing the innovations that make Agile work so well.
What if we stopped worrying about what's safe and acceptable? What if we went back to those innovative roots? What would Agile look like if we scaled beyond the enterprise?
Come find out.
If you're going to be in Bangalore in March, don't miss this. Register here.
4X Faster Time to Market: An Interview with Autotrader
We recently had the opportunity to interview Nick Park, director of experience delivery, and Sherolyn Sellers, manager, process delivery at Autotrader, to find out how their organization is using VersionOne to successfully scale agile.
In the video below, Park talks about how the structure and flexibility of the VersionOne Enterprise Agile Platform is helping teams produce great working software significantly faster.
- Time-to-market four times faster
- Visibility into key performance metrics to ensure business alignment
- Flexibility to support different methodologies – Scrum, Kanban and SAFe
- Easy to adopt and implement
- Excellent support
Autotrader, a leading online resource for car shoppers and sellers, is part of Cox Automotive. The entire organization was committed to the idea of agile at scale from the start, so instead of just focusing on agile as a technology team transformation, they looked at the positive impact that agile could have across all the disciplines within the company.
Autotrader started their agile implementation with a small pilot program with cross-functional team. The team decided to use VersionOne to give them a structure to get started with agile processes and their transformation.
After the initial pilot, other teams started asking to get into the system, so the organization selected VersionOne because of its ease-of-use, simple implementation and excellent support. It was very important to get team members up and running with the system quickly.
Autotrader took a planned approach to their implementation to make sure that they were setting up the structures of the actual work, matching it to all the portfolios, and adding team members as it made sense. The progress of adding new users has climbed steadily as they have added teams, and now they have more than 200 users on VersionOne.
With the kick start from working with VersionOne, Autotrader has seen immediate results. The teams were using VersionOne to establish their agile processes and make changes to adapt to their business along the way. After three months, the teams were building momentum and producing working software.
In fact, Autotrader is introducing new releases at least four times faster than before implementing VersionOne now that they have the structure, processes and the visibility to more efficiently manage the work. In addition, defects are decreasing and product quality is increasing because of the level of detail that the teams can capture in the solution.
Stakeholder satisfaction is extremely positive now that the organization has the visibility to manage team velocity, project burndown, and other key performance metrics to make sure they are on track with the goals of the business. Now executives have easy access to the data they need to see progress and make more informed decisions on the prioritization and sequencing of projects. In addition, since Autotrader is part of Cox Automotive, they are adding new procedures and processes so they can start to visualize how projects are aligning with the corporation’s strategic view.
As Autotrader has grown, the fact that they have been using VersionOne since the beginning has allowed them to scale agile without that ever being a concern. Currently the organization has more than 20 Scrum teams and is managing projects at multiple tiers. Autotrader managers are able to use the epic board to see how work is flowing through the system, understand how expectations are being met, and identify any roadblocks or dependencies that need to be resolved. VersionOne has become a critically important system of record.
It has also been important that the inherent flexibility in the VersionOne platform was able to support different roles and methodologies. Autotrader has Scrum and Kanban teams and they are also using the Scaled Agile Framework® (SAFe®). Even though the teams leverage VersionOne in different ways, they have a common platform for overall reporting to make sure there is alignment with the portfolio and initial investments from their leadership. In addition, the ScrumMasters and Kanban leads have the platform to start building their own community of practice.
According to Sellers, “Hands down, the teams love VersionOne. I have implemented several solutions throughout my career and this is one of the easiest for the users to adopt and use right away. In addition, the support has been great. There’s not a single time that I felt like I was ‘on an island’ and couldn’t get answers to our questions in a very timely manner.”
Please visit VersionOne’s YouTube page for more video interviews.
The post 4X Faster Time to Market: An Interview with Autotrader appeared first on The Agile Management Blog.
“If you want to build a ship, don’t drum up people to collect wood and don’t assign them tasks and work, but rather teach them to long for the endless immensity of the sea.” – Antoine de Saint-Exupery
This quote comes up every now and again in agile circles. It’s almost as if we are saying something like this…
“If you want to transform an organization, don’t drum up people to form teams and write user stories, but rather teach them to long for self-organization and empowered enterprises.” – paraphrase by Mike Cottmeyer
I think much of training in our industry is like this. I think the primary focus of the CSM class is less about agile and more about teaching a longing for the endless immensity of the sea.
What happens though, once I long for the endless immensity of the sea, and now it’s time to build a boat?
Once I desire self-organization and empowered enterprises, what do I do to make that happen?
There is this notional idea that once we see it, once we have everyone on board, once we get a sufficient cultural shift going… people will self-organize the boat.
There is a popular book going around right now called ‘Turn The Ship Around’ by David Marquet. I got to meet David a year or two ago in Copenhagen and read his book.
It’s a good read.
The general idea behind the book is that we should give control rather than take control. That we should create leaders rather than forging orders.
One of the things that I think is missing from much of the analysis of Marquet’s work is the context in which he gives control and creates leaders.
The ship is built. It has an operational model. People have well defined responsibilities within the system. Policies and procedures exist to guide them how to do their job well.
David is not teaching his people to love the sea and empowering them to make all the rest of the decisions by themselves.
They are empowered within a well defined framework, within a well defined context, with clear objectives and training for how to do their jobs.
To that end… I think we’ve asked the world to long for the endless immensity of the sea and the world has said yes. Now it’s time to start developing ship builders.
What does it mean to have an agile operational model? To have well defined responsibilities within the system? What are the policies and procedures that exist to guide us on how to do our jobs well?
This is the stuff of an agile transformation.
It is not enough to long for self-organization and empowerment.
We need ship builders.
People that know how to develop agile systems of delivery.
People that know how to operate an agile enterprise.
People that know how to craft policies and procedures and training so folks know how to do their jobs well.
We long for the immensity of the sea… and that is not enough.
A WatchMeCode subscriber recently asked a question about error handlers with Node and Express.
In his scenario, the subscriber wants to have a series of routers to handle requests to /api. Within these routes, he wants a generalized error handler that will return the error as a JSON document instead of rendering an HTML page as the default handler does. So, how should this be done?
The question is as follows:
What are your thoughts on using router-level / router-specific error handlers?
Until now I’ve been modifying the generated error handlers, from express-generator, to detect if the requested path was prefixed with /api. In those situations I was passing back an error message instead of rendering the error view. However, this means that everything needs to be buried under /api… which is not always desirable.
The short answer is, Yes! Use router-specific error handler. The long answer needs a bit more dissection…Error Handlers Are Just Middleware
When you run the Express generator, it provides a sample for a default error handler in the app.js file, similar to this:
When you look at this code with a bit of cleanup, you’ll see that error handlers are just middleware with a specific number of parameters for the callback function.
Since this is middleware, but has no route specified as the first parameter, it will usually be the last function to be called in the middleware stack of error handlers.
Knowing this provides a lot of power and flexibility for making use of router-specific error handlers, and facilitating the /api specific handlers to return JSON data instead of rendering a web page.An Error Handler For /api
With an understanding of middleware and knowing that error handlers are just middleware, it’s easy to provide an error handler just for the /api routes. You only need to “use” a middleware error handler with the “/api” route passed as the first parameter:
Now any time an error is returned through a “next(err);” call from within any “/api” routes, this error handler will be executed. This error handler will send back JSON data, as an API would expect to receive, instead of trying to render HTML.
For any other routes that aren’t part of “/api”, the default error handler in the app.js file will still be used and will still render HTML as expected.
And if you find yourself sitting in the error handler for “/api” but you know the error should not be handled in this location, you can forward the error on up the middleware chain by calling “next(err);”.
This update to the previous error handler will forward the error to the next handler if the specified condition is true, allowing the default (or next) error handler to have a chance to work.Global, Routes and Sub-Routes
Knowing error handlers are just middleware, like everything else related to routes and routers in Express, makes them very powerful and very flexible.
The default code from the Express generator command line tool will give you a “global” or last-ditch error handler. This is a good place to start for your error handler needs. And with a little bit of code and thought process, you can easily provide route and sub-route specific error handlers, as shown above.
Want To Keep Your Routers / Routes Clean?
With great flexibility comes the potential for a great mess – and Express routers are no exception to this. It’s easy to just cram routes into a single .js file and be done with it, but this quickly becomes unmaintainable. Add error handlers into the mix, and you’re only adding that much more to the mess.
So, what are the secrets to keeping routes, router files, error handlers, middleware and other bits of code in your Express app clean?
As more teams and organizations transition to agile, they discover something important about leadership. Leadership is part of everything we do in an agile project. It doesn’t matter if it’s development or testing, management or architecture. We need people with high initiative and leadership capabilities.
That leads me to these questions:
- We need project management. Do we need project managers?
- We need management. Do we need managers?
- We need architecture. Do we need architects?
As with all interesting questions, often the answers are, “It depends.” What do those people do? How do they do it?
In December, I gave a talk, “Agile Architect as Servant Leader” for IASA. That talk outlines some of the ways agile architects might work as servant leaders. See the slides: Agile Architect as Servant Leader.
There is more about servant leadership in Agile and Lean Program Management, for program managers, program product owners, and architects.
Here is the link to the recording: Agile Architect as Servant Leader.