Where to start?

A question that I've been asked several times is where to start with improving your software engineering practices. Based on my experience, my answer typically is "It depends." Let me explain.

In one of my previous roles the release cycle was very long. This was not because we didn't want to release more often. It was simply because the system was very large and there were only few customers. Typically the upgrades would require significant manual intervention anyways. On the other hand, quality was a real issue and starting the improvements in that direction was a good choice by introducing a set of new tools, new designs, new technologies, new equipment, and new process. It was very focused on the inside of the development team.

In my current role we moved from one major release per year to monthly release cycles earlier this year. And although there were some concerns with it we were able to mitigate the impact in such a way that our clients can choose their own upgrade cycle. Whenever there is a feature of interest in a new release they can upgrade from their current version to the latest version in a one-step process. There is no need any longer to upgrade to the any of the versions in between. So, while we still offer new features each month, no client is force to upgrade on a monthly basis. There are, though, some clients who do, and each month there are clients who upgrade to that monthly release.

With this background it has become clear that just moving to monthly releases wasn't enough. Instead we combined it with significant efforts to simplify the upgrade process for our clients. And the feedback we get from clients in different geographies is very positive. Therefore we will continue improving the upgrade process so that it becomes even easier for our clients to move to later and even better versions of our software. With this ever-improving upgrade process in place we have established a delivery mechanism that allows us shipping new features faster to the market place. New features are picked up sooner and we receive feedback and suggestions faster as well. Our clients benefit from earlier availability of new features that in the turn allow them to run their business more efficiently.

In the second example I focused on the delivery process first - short release cycle combined with easier upgrades - while in the first example I focused on an improved engineering environment first. In the second example think of this: What if you had the perfect product but it would be a nightmare to upgrade? It would be very difficult to get improved versions installed on client's sites. If on the other hand you have a very simple upgrade process (and hence delivery process) you can roll out product improvements much faster.

There is no hard and fast rule what to do in each scenario. The key learning is that you need to identify what the determining factors are for your team's environment. Then create options and see how they would address the biggest challenges in your situation. Start in one place, and start small. Then observe and take the next step. And make sure you line up your team members. In particular their creativity and innovation are key elements to selecting the right starting point and to successfully move from there.

Mini SWAT Team

Similar to the build master role - I posted about that a few weeks ago - you may find occasionally that there are other topics that you want to overemphasize for a certain period. The build master is specifically taking care of continuously improving the engineering and build environment.

But you may have items that are either to beyond the available build master capacity or don't even fall under the build master's duties. Or you want to speed things up. Let me give you two examples.

Let's say you want to introduce a new testing tool that you haven't used in the past. The tool arrives. While rolling it out you find that there are challenges and issues that need to be addressed. Not that you are surprised but the amount of work is way beyond of what your build master (or build master team) can do within their time. So what do you do?

Or you want to migrate your build environment towards a substantially improved environment, more powerful, more flexible, maybe involving virtual machines, new technologies, and so fourth. A steep learning curve is guaranteed. What do you do?

In both cases you can create a "Mini SWAT Team". This can even be as small as one person. The mini SWAT team would be dedicate to one particular subject for a period of time and then wrapped up. In the first example the introduction of the testing tool could be sped up by working with the QA team and by working with the developers. In the second example the mini SWAT team could work with IT on the environment improvements.

Who would you put on your Mini SWAT Team? Certainly you'd look for someone who can work independently but also in a team. People who can work with different functions are certainly advantaged. But then, you also have a quite different option as well: Give it to a more junior member of your team. Provide a lot of support and you'll find that the person steps up and grows with the job, enjoys the responsibility and the opportunity to pull something through that is of value to the whole team.

Food for thought? I hope so. It's all about trying something new and then adapting as you go!

Taking turns in being the build master

The build master is a quite important role in an software development team. Responsibilities include ensuring the build works all the time and chasing down people who are fixing a broken build. Other items may include improving the build process which should also include the execution of comprehensive test suites in all test beds.

While on one hand it is a big help if a person in this role has prior experience with these tasks. On the other hand - and that doesn't have to be a competing goal - it is also valuable if team members take turns.

Let me explain. In all teams that I have coached I have found that different people have different strengths. For example one person might be excellent in writing Perl scripts while a different person is extremely proficient in relational database systems. By taking turns each individual can emphasize their area of expertise in the build master role. That way, if the skill is important to the whole team, the skill is also important for the build master role. Eventually all areas of expertise will get addressed eventually.

One more benefit of taking turns is that all team members walk in "the build master's shoes". There is a much better understanding of and buy-in by the team for build master related tasks and challenges. The response to being chased down because of a broken build will be tainted quite differently than if the same person is in the build master role.

At the moment I'm experimenting with swapping the build master role at the end of each release cycle (currently one month). And already the above mentioned effects have become visible.

---

Also check out "Manfred's DotNet Blog"

The Choice of Not Being an Elephant

Lou Gerstner described in his book Who Says Elephants Can't Dance?: Leading a Great Enterprise through Dramatic Change
how to make even a very large organization more agile, more adaptive to changing conditions. IBM had no other choice since some of their old business models stopped working. When I speak with people who were decision makers in the 1970s they unanimously told me that there was a time where the sales guys in dark blue dresses almost walked in to their customers and just said "sign down here". The customer had little choice.

Even if these stories are exaggerated - I'm not a sales guy but I'm sure their stories are always true! - there is one interesting aspect to this. I'm also mentioning this since I just came back from a trade show and there I spoke to a manager of one of the largest vendors in that particular industry. Somehow that person made me think of those stories from the past about IBM.

Like IBM in the IT industry this person's company is a key player in their industry. And the way the person came across was almost as if he was saying: "We know what is good for the industry, for you. Just do what we say, sign here and everything will be right." Sounds to me a little bit like "We are the center of the universe and all other companies better lign up around us."

The conversation left me wondering by when their CEO will write a book about how she had to turn their company around? Maybe they haven't noticed yet that the downturn in the industry probably requires them changing their attitude as well. But maybe I'm totally wrong and they still have full order books and the customers are lining up to the horizon. Not long ago, however the news were saying they are in the process to make a large number of people redundant.

That doesn't sound to me like full order books... The news of redundancies along with the attitude of the person I spoke to appear more like a company that isn't yet set up flexible and adaptive enough. Maybe reading Lou Gerstner's book helps.

---

Also check out "Manfred's DotNet Blog"

How Pair Programming Reduces Distraction

Pair programming is not for everyone. Some people love it, some people hate it. It almost seems there is nothing in the middle.

I'm more in the camp of people preferring pair programming. For many different reasons but I keep the discussion for a different post.

In this one I'd like to describe an example for what happened to me yesterday. I was working with one or my fellow software engineers, Jason, and while we were looking through a nasty C++ link problem we discovered a small item in an adjacent code area that we felt should be cleaned up. So I took a card and wrote it down as a story and returned back to the problem at hand.

Jason was surprised and made comment saying that by taking a note we would actually avoid being distracted. Although I have worked like that for years my colleague is newer to pair programming and that was probably the reason why he noticed what I did. For me it was just normal mode of operation. I did it unconsciously.

Based on my colleagues observation I think there is a lesson to be learned: First there is the specific case. When you come across something that should be done then just take a note (create a 'story' card). Don't let yourself get distracted. That way there is only a small interruption and then you are back on the problem at hand. Secondly, don't assume that the way you work is normal in the sense that everybody knows all the techniques you are using. It pays off to make yourself aware of this and sometimes it takes a good observer like Jason making a comment to become aware of what you are actually doing. So keep your ears open!

How fast do you adapt?

Here is a quote from today's online edition of The Wall Street Journal:

President Obama said that Chrysler has been "a pillar" of the industrial economy but that the company moved too slowly to adapt to a changing market.

(Source and more details: The Wall Street Journal, retrieved 01 May 09)

What caught my eye was the word "adapt". By the looks of it - I agree with the assessment - Chrysler didn't adapt fast enough. Now it has filed for Chapter 11, a bankruptcy process that protects it while going through a restructuring.

I'm not happy to see anything like that because many people will be severely affected in their personal lives. However, this is an (extreme) example of what can happen if you don't move fast enough as a company. Chrysler's product mix is no longer a good enough fit for what the market demands. The economic downturn just amplified that.

What can we learn from it? If we don't adapt fast enough to changing market demands and conditions it could mean very bad times for the company or the end of the company. Need any more incentive to adapt?

Can you make it right for everybody?

Yes, you can try as hard as you want. Don't we all try to provide an environment that allows people to grow and be their best professionally?

I think this is an important ingredient for a high-performing team. There are limits, however. For instance if you have a team member who isn't particularly keen to actively support changes. Not that I would be surprised by that. People have different personalities and while most are fine with change for a good reason occasionally there are people who resist all kind of change since they may have different preferences and experiences. And that's fine.

If you have a team member with an excellent skill set and huge amount of knowledge and experience that's fantastic. But what if that very person isn't able to proactively work with other team members to help them becoming better as well? What if you have a team member who doesn't attend the first daily stand-up meeting (aka daily Scrum) and comes in late once the meeting is over? What if on day two the same person comes in late but doesn't join the Scrum although it is still on? What if on day three the person is in the Scrum but doesn't participate actively? What if on top of that you observe that it even seems to have a negative impact on the rest of the team?

I think at some point you need to consider your options. Having one-on-one's for coaching is important and helps in most cases. Attempting to consider individual preferences is good, too. But once the overall team performance is affected, you need to act. And don't let anyone hold you hostage. As a leader and coach you need to keep in mind the future of the entire team and the project and objectives the whole team is working on.

An agile environment is not for everybody. There are organizations that work differently and it seems to work for them. Based on my experiences, however, I believe that agile principles work better if properly applied. In some cases this could mean that you may have an individual on your team who has a different perspective, and you should be prepared for that individual moving on. That's just fair and part of the overall change process for the team (and in fact for that individual, too!). Both the individual and the team are most likely better of.

If you have tried everything you can think of and still it doesn't work out, don't feel like a complete failure. You are not! Think of your team and about where you want to take them. And then adapt and move forward. Don't look back unless you want to learn from the past!

Projects - Do you need them?

In some companies projects are an important concept since they represent a piece of work, well defined at the beginning, maybe with a business case outlining the commercial benefits, with a project to sequence the tasks and to track progress, and with known deliveries at certain milestones and at a specific date. So far so good. There might be a problem with that, though.

What if your projects are too large? And by large I don't mean the projects that run for several years. More than a month can already be too large depending on your circumstances.

For example suppose you would like to be in a position so that you adapt as quickly as possible to changes in your environment. Customer's preferences can change. While maybe two years ago best use of limited resources was important maybe today it may be cost reduction to get through the recession.

For instance here in New Zealand the new fiscal year has started at 1 April. Many companies have taken this as an opportunity to rethink their position and options. I have spoken to many friends in different companies and to recruiters. It seems as if quite a few companies have made substantial changes triggered by the planning of the new fiscal year and as part of the approval process for new budgets.

There are many other events that change the environment in which you operate. And it appears as if those changes come in shorter intervals than maybe ten years ago.

A project of 2 months might already be too large as it might force you to lock in your team's capacity for that entire time frame. Then what do you do if something changes and you'd like to direct your team onto a different piece of work? Put the project into the bin?

Maybe there is a different notion, a different concept that you can use. What if you could split up the work required to be done by the team in even smaller chunks. For example in the company I currently work for we have many customers who work with us as a partner. Through this work, based on mutual trust and interest, we gain a lot of insights into how we can improve our products. Many small though very valuable enhancement requests are generated through this process, many of them only a few days work, a couple of weeks at most.

What if you'd look at the set of enhancement requests as a stream of small work items (one item batches) as opposed to projects that combine many such requests (large batches). Moving towards using smaller batches, ideally one item each, works better if you optimize towards processing those. Toyota calls this one-piece flow.

I think that is worth considering. Thinking small instead of massive grand schemes. There is more to that, in particular how you get started, what tools to use, and how to make it work. Stay tuned!

Navigating: What do you mean, captain?

OK, I can't speak for all industries but I can understand that you'd like to hear a few more concrete things you can do navigate these times. Let me share a few things from my software engineering perspective.

One of the options you could look at would be virtualization of parts of your development environment. An area that often proves to benefit is everything that has to do with testing. For instance if you have physical machines to test your application it might be very time consuming to set it up from scratch. You can speed this up by using an image that you can play back on the test machine. With virtualization you can become even more flexible or faster.

Some solutions allow you to create templates of virtual machines. Examples include a server with a specific database server product or a client machine with a particular browser version. If all it takes to select one each and instantiate it you can significantly speed up testing by reducing the setup time. And on top of that some virtualization products have features that allow automating a large variety of setting up virtual machines. And if you don't need them anymore just throw the VMs away. Just like that!

Another area that is worthwhile exploring for becoming leaner is everything that has to do with documents in particular internal documents. Look at all graphs for instance that require manual updating. Is there a graph that can be replaced by a simpler version or by a graph that is automatically generated and updated? Also, in some cases you may be able to simply some documents by replacing some text by tables.

Tools is yet another one. Are there tools that you can upgrade or add that will help your team to off-load more tasks to the tools? Do you use an out-date version control system? How about your automated testing tool? Automation and simplification are key regardless of whether you look at processes, tools, technology, or others. Can you simplify the design or implementation of your product? Can identify a technology that you use in your product that has outlived its usefulness?

There are plenty of options. Keep your mind and eyes open. Observe. Challenge. Put practices under scrutiny. Do they still make sense? Experiment. In small doses. Try out. Maybe you fail. But chances are that what you try will help you to focus even more on what is important in these difficult times.

And at at the same time you will become even more flexible in terms of how to respond to changes in these uncertain times. It's not the changes that hurt. It is how we respond to them.

I'm sure you got my point and are able to translate this into your industry and your specific situation. In particular in difficult times it pays off to have plenty of options for how to navigate through them!

Navigating Difficult Times

I chose the word "navigating" deliberately. The current economic climate is very difficult for many people and companies throughout the world. And chances are that you are affected in some shape or form as well.

It appears that no 'rule' that worked in the past applies to the current situation. Is that really true? I think it doesn't really matter. The important bit is that if you carefully choose an approach that lets you quickly respond to whatever is waiting for you around the next corner then you will be better off in all likelihood.

Some people and companies still try to come up with a grand plan for how to go forward. And as long as that plan is really more like a description of the direction and the principles to be used I think that is fine. But what good would it do to you if you would spend planning time right now on what you would be working on in 12 months time if all that matters is what you are going to do next month, three months from now, or six months from now!

Respond and adapt. Do both as quickly as needed (but not faster!). Instead of locking down your plans for the next 12 months use rolling plans (a planning tool, actually), e.g. for the next 3 months or for the next 6 months. Then update these plans on a regular basis, either monthly or triggered by new relevant information that warrants a revisit of your plans. If your plans cover 3 months they are much easier and faster to adapt to new insights than plans at the same level of detail that cover 12 months. Trying to update plans that cover a larger time frame tends to result in a lot of waste.

Navigating these difficult and uncertain times is definitely easier if you choose an approach that allows for much faster response and adaptation to the changing environment. At the same time you will be much better off once your markets start to improve again.

Encouragement

How do you know your team is making progress? And how can you support them in doing so? I think it is not that hard.

One technique is to observe what they are doing and how they operate. Keep a log of your observations in particular of successes and to a lesser degree of the failures. Of course not in the sense of big brother. But more in the sense of helping people realize where they are coming from, what journey they have already behind them, what successes they had, etc.

A few weeks ago I noticed that one of my teams started to use a backlog for prioritization and planning and a burndown graph for tracking progress. Recently I observed the first stand-up meeting that took place in the team area instead of taking place in a meeting room with everybody sitting down.

It is successes like these, and acknowledging these, that helps people seeing things in perspective and understand how they are moving ahead. Encourage your team if you see positive things happening!

MindManager 8

I have written about MindManager before (here, here, here and here). A few months ago I finally took the step and tried out version 8. I never bothered installing version 7 let alone trying it out after I have received comments that other users had similar issues (in particular performance) in version 7 that I observed in versions 5 and 6.

Now here is the nice surprise: Finally the software is a useful tool from a performance perspective. And I don't have to switch off hardware acceleration.

And apparently some more work went into improving the tool. It has become easier to to selection the handles to modify the curves representing a relationship between two nodes. In previous versions it sometimes took selecting other elements, then selecting the relationship again to be able to hit the handle. It's not perfect yet but at least usable.

With regards to the performance I need to be more specific. The load time is now a little bit of an issue. I sometimes think for a moment whether I really want to close the program since starting takes quite some time. I'm not sure what it is doing, maybe counting each bit of my laptops memory? Once it's loaded working with maps is very smooth.

There are items in version 8, though, which would benefit from putting some more thoughts into them.

The Outlook addin doesn't seem to be up to it's job. After I installed it Outlook became very unstable. After I disabled the addin things went back to normal. So in the meantime I'm not using the Outlook addin. And quite frankly: I'm not missing it! What exactly were the benefits of the addin?

Another area worth considering is how call-outs can be placed in a map. Sometimes I wish I could place them further out on a map or close to the node that it is related to. However, if that node has many children and all are expanded the call-out has to be above or below all of them in terms of vertical position. That way the call-out ends up to be very far away. The layout algorithm should allow more freedom for call-outs.

So bottom line we are now looking at a product that has reached the maturity that as a leader you would expect from productivity tools. A few minor areas remain that MindJet should consider. But for now MindManager 8 is a very valuable piece of software and I use it on a daily basis.

Note: I'm not affiliated with MindJet or have any financial interest in the company or the product. The opinions expressed in this post are entirely my personal view and are not paid for.

Changing People's Mindset

One of the biggest challenges with building and fostering an agile team is to change people's mindset. It didn't take me long to realize that brain washing is not an option, although it is very tempting!

There are different approaches. One approach is to wait until a good opportunity comes up. For instance if there is a particular bug that was extremely painful and maybe somebody suggests to add one more step to the build process.

That's your signal! Ask what that additional step is and ask for more details. Then ask whether the additional step can be automated. And if the answer is 'yes', then ask to add the automation of that step to the build masters backlog. You don't have a build master? Well, then you have just identified yet another item that the team should put in place. You don't have a build master backlog yet? Well, there you go! Yet another opportunity.

So bottom line: This one single event can trigger the introduction of no less than three agile techniques: Automated Testing, Build Master, and Backlog.

The more I work with teams the less I see the need to push things out. Instead there are actually quite a lot of opportunities that present themselves. In other words: You don't have to wait long until such an opportunity is there. And then you can suggest the techniques that worked wonderfully in the past.

And by asking the right questions, again and again, including "How can we test this?" and "How can we automated this?" you drive your message home. Asking the same questions again and again will make sure that people start to change their minds. I have seen it more than once. Just keep insisting on answers to those two and similar questions. Be gentle but insist on those answers. It will pay off!

Introducing new tools

As a leader you may find yourself in the situation of having introduced a new tool. And then maybe you observe that the team doesn't know how to use it. The reason might be that they haven't yet fully understood the underlying principles and so if they hit a road block they might not be able to adapt.

Resist to the temptation of then doing the work for them. It's not worth it and doesn't scale. Instead work with the team and demonstrate to them how the tools is supposed to be used. Then give them another try encouraging them to come back to you for more assistance if they get stuck.

For instance: Assume you have introduced a spreadsheet based tracker (for an example see the Agile Tracker) including a backlog and a burn down graph. One way of introducing this could be to identify a significant portion of the work that is very similar and of which the items can be counted. The resulting backlog may not contain all the full piece of work required. Hence you and your team don't know yet whether the work can be completed on time. Ask them to include every single piece of work that is required. Ask them to prioritize - or if necessary triage - all tasks. If they struggle how to do that, use a few examples to demonstrate the use of the tool (the tracker in this case), then ask them to try the rest by themselves.

I believe this works better than if as a leader you would be involved all way through. Be available when needed. Make sure it is understood that asking for assistance is not a sign of weakness but a sign of strength. Briefly discuss their experience so far. What went wrong? What worked? Then provide just enough to get them going again.

Some Non-Cash 'Carrots'

Leadership sometimes requires finding a 'carrot' to make things happen. Not always does the 'carrot' need to be cash or other monetary items. Let me give you two examples.

In one case I worked with development team that wasn't keen to try pair programming. However, I observed that they were using pretty old computers for development and they were not happy with the performance.

Therefore I purchased a couple of high-end workstation, shiny, brand-new and fast, along with really nice large flat panel displays. I also got a desk for each of them so it would be easy for two people to sit next to each other on those desks. And finally I announced the rule that these boxes are dedicated to pair programming hence the powerful machines.

It didn't take long for the 'carrots' to show an effect. Slowly first but then more and more people tried it. Some only for a short time, some for more. And eventually I had to get more such machines and the team was totally hooked.

In a different case I was working with a team that was sitting on very old C++ code. The available tool set was appalling, and so I gave the team the direction to get onto Microsoft .NET, in particular C# where a much better tool set would be available, including good refactoring support, unit testing, and better libraries. And all the memory management crap would disappear as well.

Again it was close to impossible to get there. And some of the reasons given were just fine. For instance there were significant technical obstacles to make that shift easy.

Therefore I asked one of the team members to find out how to move the native C++ code to Managed C++. Sure, that wasn't straight forward either but it was an enabler and good step in the right direction. As a consequence it became much easier for the team to mix and match Managed C++ and C#. And since the tool support in C# was much better, more and more code was eventually written in C#.

These are just two cases where using an appropriate 'carrot' helped the team to move faster towards a desired outcome. Sure, in particular the second example is a bit special. Yet, I am sure that you are able to find more 'carrots' which work in your particular situation. I'd be interested in what you find out!

Two More Thoughts About Selecting Tools

In a previous post I shared a thought about selecting tools, in particular whether you should decided for a tool just because you happen to be a partner of the vendor.

Here are two more thoughts about selecting tools.

Driving Towards A Decision

The first one deals with ensuring that the decision making doesn't take forever. Sometimes teams discuss about tools for weeks or months without coming to a conclusion. As a result they don't have the tool. And as a consequence they don't enjoy the benefits.

For instance you are considering adding a particular type of test tool to your tool set. Of course there is the danger that you may select the wrong tool (I'll discuss below how to mitigate that risk). On the other hand even a tool that is not a perfect fit but at least does a perfect job is better than no tool at all. No testing tool is even worse than a testing tool that may be usable only for very specific test cases.

Therefore it is important to drive to a decision. And the best technique is time boxing. Give your time a time box and insist on a decision by a specific time. Only extend the time box if an excellent reason is given. That way as a leader you can steer the team towards a decision.

And if the the team can't come to a conclusion? Well, you can always use the threat to make the decision yourself....

Homeworks

While it is important to reach a conclusion you also want to make sure that the team makes a proper assessment of the different options. I usually expect that the major player are being looked at and compared. As a tool I recommend a decision making matrix by which the columns are the different products and the rows are the selection criteria.

To get the team started I describe to them how the tool works. Don't assume they already know. Make sure they do. Next I also tell them that I won't provide them with the full list of selection criteria but that I expect them to choose those as well before they start the assessment. I guess the management speak for that would be "empowerment".

Usually I make a small number of selection criteria mandatory. For tools these are:

• Ability to be launched from a command line
• Ability to deliver the result as an XML file (or other standard format)
• Price for chosen configuration, e.g. based on number of license required

The first two items are important from my perspective since a tool needs to be easy to integrate into automated processes. By using command line and standard-format based files (XML preferred) only little 'glue code' is required if at all.

Why the decision making matrix? First, you will notice that the team will then have a recipe for their assessment. They know what questions to ask and what to find out about the tool. Second, the team will gain an overview of the major players for each tool. Often team members have different backgrounds and experience with different tools. By working together the decision will become data-driven and facts-based as opposed to 'I like tool A more than tool B'. Also the team will have a basis on which they can have a meaningful discussion. The result is much more detailed and specific.

And finally, you will observe that all the sudden all major vendors are looked at and a better decision is made. You can take the outcome including the decision making matrix to create the business case that you may need for the purchasing process anyways. And even if such a business case is not required it still is an excellent exercise to go through some number crunching to determine by when a particular tool is fully paid off and what ROI it creates.

Decision Making Styles

Making decisions is probably one of the most important activities of any leader. There are plenty of different ways to make decisions. I like the way how it has been described in Peter Senge's book "The Dance of Change":

• Telling: Make a decision and just tell the team.
• Selling: Make a decision, explain why you made that decision, then tell them to do it.
• Testing: Identify a problem, present your solution and ask for the team's comments.
• Consulting: Identify the problem, tell them you don't have a solution and ask them for their suggestions.
• Cocreating: Identify the problem, then come to a decision as a team.

While cocreating probably creates the most buy-in from your team, you may have to make decisions using one of the other styles occasionally. For instance you may have become the team leader only recently and a problem is so pressing that any further delay creates a lot of additional damage. Then it might be right to just make a decision, explain it and then have the team execute it (Selling).

One of the factors that may influence the style you want to use is maturity of the team. In very mature and homogeneous teams consulting or cocreating might be very fast approaches. On other teams different factions may simply not converge even if you give the team a generous time frame.

Again, it pays of to adapt to the situation at hand. The more of these styles you can easily work the easier it will be to select the most appropriate one, and still get decisions made both fast and properly.