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.
“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.
The Scrum Myths videos have been popular and I’m very happy with people’s comments about the videos. I’m going to be making an even more extensive new series for publication in just a few weeks.
Unbeknownst to me, the videographer, my brother Alexei Berteig, created a bloopers video from some of the many, many, many, MANY mistakes I made while making the videos. I hope you will watch it…. but I strongly recommend taking a look at one or two of the “good” videos first. Try these:
Now, without further ado, here is the Scrum Myths Bloopers video:Learn more about our Scrum and Agile training sessions on WorldMindware.comPlease share!
The post Fun Video: Bloopers from the Scrum Myths Video Series appeared first on Agile Advice.
The Agile Retrospectives Books Bundle has a new addition: Agile Retrospective Kickstarter by Alexey Krivitisky.
The Retrospective Cheat Sheet lets you create numerous unique agendas for your retrospectives. This book provides the details to the exercises based on the team mood, size, proximity. It is a handy kickstarter for people interested to start up or spice up their agile retrospectives.
Patrick Kua, Ben Williams and Tom Roden, Taina Caetano and Paulo Caroli, Jutta Eckstein, Alexey Krivitsky and Luis Gonçalves and I have published books about agile retrospectives on … Continue reading →
Failing because you made an informed choice, took a calculated risk, or even made a bet, understanding the odds were against you… is fine.
Failing because you were sloppy, didn’t do your homework, didn’t work hard, or didn’t care is a totally different kind of failure… and isn’t fine.
It is different failing from acts of commission than failing from acts of omission.
I tell my team often to error on the side of movement. To error on the side of doing what’s right. If we are trying new things and we fail… so be it.
What drives me nuts is failing because we knew what to do and just didn’t do it. Failing when we knew the truth and didn’t tell it.
If we are going to fail… it is important to fail fearlessly… and for the right reasons.
Happy New Listening in 2016 ! Are you ready to be surprised by what you'll discover ?
Ready to Observe When I'm brushing my teeths in the morning, , I ask myself :
- How ready am I to listen today?
- How do I intend to drop the "voice of judgement" and the "voice of fear" today ( from the TheoryU) . I don't recognize myself as a "voice of cynism" representative, so I don't yet focus on this one . I should , as there no such thing as the filters that we apply to ourselves.
- How will I be able to let things happen on their own agenda , observe them, and enjoy all the unexpected values they can bring?What are the questions are you asking to your mirror in the bathroom each morning? Leading from the Future There is experience, there is now, and there is hope. In experience lay all the answers to the "morning-bathroom questions" we already gave and lived by .Observing my world as it is today, is an infinite potential. Now here is the kind reminder : Observing means really "unjudgmental" observing. I mean, really! When you grab that toothbrush this morning ( or the door of your office , or your cell phone ...) think you are a three year old kid , or imagine you are an alien on an unknown planet, amazed by your journey on Earth. As a good observer extraordinary ideas may just pop into your mind . I had in 2015 an epiphany about the "active" part of what is called "active listening". Before this attitude will get turned in another fancy inter-relational tool , I realised that active means that things are really changing just by observing . Other people attitude , the knowledge about ourselves and our ideas of how the future can be .
So, let' get ready of tomorrow : What question would you like to ask yourself in the bathroom each morning for the next days of the year ?
Related Posts Manage like A PirateWhy I Am Not A Change Agent
This time of year is always a great time for me. As a consultancy, what happened in November and December has already happened. There isn’t anything we can do to influence it.
January is similarly fixed because there isn’t much you can do to get people busy if it’s not already on the books.
We put a ton of energy into making sure we close our old year well and are set ourselves up for the first month or two of the new year.
What that means from a business perspective, is that the last two weeks of December, and the first two weeks of January, are incredibly quiet.
This is my 6th year running LeadingAgile and there is a clear pattern emerging. When I get the noise of running the company to quiet down, I get creative and want to write.
Over the past few weeks I’ve shelled out something over 20 blog posts that I just need to type up and get on the site.
We’ve been working on company strategy and have a ton of changes in the works for the website as we build out infrastructure to explore the new directions.
We’ve got Agile2016 in our home town this year and are looking forward to throwing the biggest party you’ve seen at an agile conference… ever.
As a company, we’ve put a ton of energy into building a rock solid business infrastructure and plan to fully leverage that infrastructure to do some cool things in the new year.
I’m super excited to get 2016 going. Looking forward to having all you guys along for the ride!
We are excited to announce this new release of the Scaled Agile Framework® (SAFe®). 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.
To help with the migration to 4.0, SAFe 3.0 remains available and supported at v3.scaledagileframework.com.
SAFe 4.0 incorporates learning from all prior releases—including the SAFe for Lean System Engineering development branches—into a single, more scalable and more modular framework. To address the broader set of capabilities, SAFe has a new name: SAFe 4.0 for Lean Software and Systems Engineering.
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
In addition to the new 4.0 content, all the 3.0 articles have been updated as well, so there’s much to learn, and gain. For those of you certified as SPCs, we’ve provided a What’s New in SAFe 4.0 Video that will help you learn about the new features, and upgrade your certification so that you can support enterprises seeking SAFe 4.0 implementation.
It is our sincere hope that this new version helps you and your enterprise achieve the benefits you all deserve for working so hard at building the world’s biggest, and best, software and systems. And, as always, SAFe knowledge remains freely revealed, for all to use.
We owe a special thanks to you, our SAFe community, for all your feedback and support. Your passion for the best SAFe possible has driven us to deliver what we now like to think of as the most adaptable framework in the world.
—Dean, Alex, Richard, and Inbar
Dean Leffingwell, CEO and Chief Methodologist
Alex Yakyma, SAFe Principal Consultant and SAFe Fellow
Richard Knaster, SAFe Principal Consultant and SAFe Fellow
Inbar Oren, SAFe Principal Consultant and SAFe Fellow
Although I recently ran a personal retrospective, I also like looking back at the past year using different models to recognise progress and celebrate events.Image sourced from eye/eye under the Creative Commons licence.
Here’s how 2015 went for me in numbers:
- Blog articles written: 22
- Published (non-blog) articles: 5 (The “lead” of a tech lead, The “tech” of a tech lead, Finding harmony in the tech lead role, 5 Tips for Being an Effective Tech Lead, and Why expert developers make the worst tech leads.
- Books read: 5
- Number of conferences attended: 5 (OOP Conference, Agile on the Beach, DevTalks Bucharest, GoTo London, XConf Manchester & Hamburg)
- Keynotes given: 2
- Total talks held: 17
- Different clients: 3
- Interviews given: 4 (FogCreek, Johannes Thönes, InfoQ, Leanpub and Managing Smartly)
- Tech Lead courses given: 5
- Countries visited: 9 (Germany, France, Italy, USA, Australia, Hong Kong, South Africa, Romania, Spain)
“Chance favors the prepared mind.” -- Louis Pasteur
The future is either created or destroyed by the decisions we make and the actions we take.
It's 2016 and change is in the air.
For some people, this time of year is their favorite. It's a time of year filled with hope, possibility, and dreams.
For others, this is a horrible time of year, filled with despair, shattered dreams, and bitter disappointment.
Either way, let's get a fresh start, as we turn the page for a new year.
Let's give ourselves permission to dream big, and re-imagine what this next year could be all about.Prime Your Mind to Empower Yourself and Your Business for an Amazing 2016
If you don't know what priming is, it's a psychology concept that basically means we embody the concepts and stereotypes we're exposed to. For example, if we see the color yellow, we find the word banana faster.
You can use priming in a very pragmatic way to inspire your way forward. Rather than hold on to old beliefs, mental models, and references, you can fill your mind with examples and ideas for new possibilities.
I've written a fairly exhaustive approach to how you can prime your mind for 2016:
But I'll summarize some key ideas in this post so you can get started stirring up your big bold ambitions for the new year.3 Key Ideas to Prime Your Mind with for 2016
The big ideas really come down to this:
- People examples of transformation. Fill your head with examples of how people have created amazing personal transformation. TED Talks are a great source of inspiration and examples of how people have transformed themselves, and in many cases, how they are helping transform the world around them.
- Technology examples of transformation. Fill your head with examples of how the mega-trends are shaping the world through Cloud, Mobile, Social, and Big Data. Fill your mind with examples of how the mega-trends are coming together in a “Nexus of Forces” as Gartner would say, to change the world. Fill your mind with examples of the mega-trend of mega-trends – the Internet of Things – is re-shaping the world, in extraordinary ways. Read Future Visions, a free download by Microsoft, to get a glimpse into how science fiction could shape the science around us.
- Business examples of transformation. Fill your head with examples of amazing examples of how businesses are driving digital business transformation. Read NEXT at Microsoft to see some of the crazy things Microsoft is up to. Read customer stories of transformation to see what Microsoft customers are up to. Explore what sorts of things customers are up to on the Industry Solutions page. For some truly phenomenal stories of digital transformation, check out what Microsoft UK is up to in education, business, and society.
Here is a quick way you can use books to help you prepare for the world around you:
- Read a book like Leading Digital to get the overview of how digital transformation works. You can see how companies like Starbucks and Burberry drove their digital transformation and you can learn the success patterns of business leaders who are leading and learning how to create customers and create new value in a mobile-first, cloud-first world.
- Read books like Consumption Economics to fully grasp how value creation is throttled by value absorption – the ability of users and consumers to use the value that businesses can now create in a digital economy.
- Read books like B4b to see how companies are shifting to business outcomes for customers and helping customer achieve new levels of value from their technology investments.
- Read books like the Challenger Sale to learn how to go from somebody who pushes solutions to somebody who becomes a trusted advisor for their client and learns how to 1) teach, 2) tailor, and 3) take control. Teaching is all about knowing your stuff and being able to help people see the art of the possible and sharing new ideas. Tailoring is all about making ideas relevant. It means you need to really understand a client’s pains, needs, and desired outcomes so that whatever comes out of your mouth, speaks to that. Taking control means asking the right questions that drive conversations, strategies, and execution forward in an empowering way.
- Read books like The Lean Startup to learn how to create and launch products, while making better, faster business decisions. Learn how to innovate using principles from lean manufacturing and agile development to ship better, and win more raving fans.
- Read books like Scaling Up to master the four key decision areas: people, strategy, execution, and cash, to create a company where the team is engaged, customers are doing your marketing, and everyone is making impact. It includes one-page tools including a One-Page Strategic Plan and the Rockefeller Habits Checklist.
- Read books like The Business Model Navigator to learn how businesses are re-imaging their business models for a mobile-first, cloud-first world.
- Read books like Anticipate to put it all together and become a more visionary leader and build some mad skills to survive and thrive in the digital economy.
- Read a book like Getting Results the Agile Way to help you master productivity, time management, and work-life balance.
Best wishes for a 2016 where you create and live the change you want to see.You Might Also Like
The Agile Consortium and Unicom are organizing the Scaling Agile for the Enterprise conference on February 4. Parallel with this event the DevOps Summit is held. Both conferences will be at the Herman Teirlinckauditorium at KBC Bank in Brussels, Belgium. I will be covering these one day conferences for InfoQ.
At this second year of the Scaling Agile for the Enterprise conference we will bring together stalwart thought leaders on Agile Leadership like Jurgen Appelo, Christopher Avery, Jenni Jepsen, Dave … Continue reading →
At a certain point in reading Daniel Kahneman’s Thinking, Fast & Slow I realized I had discovered a possible explanation for the mystery of “museum sleepies”. Museum sleepies is my wife‘s term for the fatigue we feel after a rather short time in a museum, a term we’ve used much more frequently since moving to London. I know this is a common experience, and a search will find various explanations, both physical and mental. What I got from Kahneman is a better model of what’s happening to us, and — very exciting to me as a learning nerd — a testable prediction.
The focus of Kahneman’s work is decision theory, and the title mirrors the model of cognition he uses. We can imagine that our mind has two systems for processing the world and making decisions. System 1 is fast and intuitive (think Blink), unconscious, involuntary, and cognitively cheap. System 2 is our deliberate, conscious, analytical thought process that is also, unfortunately, both slow and cognitively expensive. Most of the book is an explanation of how our reliance on System 1 results in predictable cognitive biases. To get there Kahneman first describes experiments to establish a measure of mental effort, evidence that all types of mental effort draw on the same limited pool of resources, and that engaging our System 2, focusing our attention and performing deliberate analysis, draws off that limited pool.
In the larger world the findings Kahneman describes have serious implications in terms of ego depletion and decision fatigue. In our tour of the museum there isn’t much at risk, but it struck me as a application of the same findings. After reading Thinking, Fast & Slow my model for the museum sleepies is that I’m using my System 2 to analyze one artifact after another and that this is draining my limited pool of mental energy. This model leads me to predict that someone trained to analyze the artifacts wouldn’t suffer the same effects. The trained person would see the same artifacts differently because they would have a set of prebuilt patterns and categories to draw upon. They would notice the patterns largely through System 1; System 2 efforts would be brief and efficient. Finally, I expect I could use deliberate practice to train myself to understand some class of artifacts, and that henceforth I would no longer suffer the same fatigue when viewing that type of collection.
I’ve spent a lot of effort in the past few years trying to develop my abilities to promote organizational learning. Much of my focus has been on the Action Science approach to effective communication. Another part of it has been trying to teach the scientific mindset that learning is about detecting and correcting error, which we can do by making testable hypothesis and testing them. I don’t plan to conduct any cognitive psychology experiments with art historians, curators, and artists, but I love the fact that someone could. This museum sleepies story has become part of my arsenal for illustrating some important concepts in cognition, in training, and in theory making. I hope you find it useful too.