Your address will show here +12 34 56 78
Agile, Articles, Culture, General, Posts, Product Owner

Anyone who deals with Agility as a way into the future for the company, will quickly get the impression that everything has to be thrown overboard. But is that really true?

A typical situation: A medium-sized or even large company is looking for a way out of product development that takes years – but the market demands shorter development cycles, more frequent product releases, in other words “faster time to market”.

The business model, which was still profitable and innovative ten years ago, seems to be more market-driven and has unattractive return targets.

A change is needed. It seems as if the company is heading straight for its end, unless a quick and comprehensive restructuring is undertaken. Here promises Agility, which is as hype in a lot of companies, recovery and rescue. So a project is set up, it should be started small because it is still seen as an experiment by the management and not as a game changer yet. One or two teams are identified who are trying out the new method for the entire company. In a lot of cases we call this pilots (old project thinking !!!) but I prefer the term experiments.

The team(s) selected have as few interfaces to other areas as possible to make this experiment possible. It can almost not fail. It is promising so far, but you have to do a lot for these teams differently. Due to the self-organization, a Product Owner and a Scrum Master as communicators for demand and delivery are enough for the company in the first place. There is no need yet to change the leadership or structure of the company yet.

The team, all volunteers, rushes into the work with enthusiasm and can “produce” undisturbed as it can run as an experiment and has nothing to do with the rest of how the organization is structured or formed.

After about a quarter of a year, first real results are visible and will be presented in the review. Long PowerPoint presentations? Not even close. An Minimal Valuable Product (MVP) is presented. Instead of a meaningless project status report, the progress “live” on the board can be traced. Product Owners and Scrum Masters do everything they can to get the right product and keep the team productive. So far so good.

The successful project should now be rolled out to the whole company with these experiences. And then it becomes interesting. As now we have to deal with the Company Culture, structure, etc. Before I go into the reasons for doing so cautiously and with a view to a healthy degree, here are a few more points on Agility.

How much Agility is necessary?

The headline for this post is a Chinese proverb. That’s why I like it so much, because it describes what happens when you unreasonably dictate Agility.

The principles and values of the Agile Manifesto do not speak of simply throwing everything overboard. It’s about finding the right mix that transforms the business. One is more important over the other but it does not dictate that the other things are not valuable. 

In my view, it is even important to consider how far you want to go with it, because there will always be areas that do not need to be forced to be Agile. Just as you will not necessarily use Six Sigma in the boardroom of the CEO, Agile Scrum or Kanban does not make sense when it comes to clear process flows in the supply operations.

In case of a reorientation or restructuring, the company also examines which resources and skills are available, which one wishes to build up and which financial scope for investment exists. What speaks against doing that when introducing agile methods?

What should be left of the old?

Even if the goal is to create a “new” Agile structured company, it is more sustainable and more effective to check the existing for reusability. So it is real important also to know the current situation. The transition from a classic company to an Agile company is associated with enormous changes. It is not simple an investment in faster pc’s or other tools. And some changes need to be done in steps. To big steps changes are in some situation to complex.

In most cases the effort is to adjust the way employees need to change as they are used to work for a long time in a different way. As tempting as the idea is that employees lead themselves, they are more motivated and more productive: they are people. Nevertheless, or even in times of major changes, such as the introduction of self-organized teams, you need a lot of guidance and guidance on how to do that. (Agile Transition coaches, Culture- and Transformation coaches are being introduced to help to guide the change)

Complement knowledge

Of course you also need to check what equipment the company brings with it, and investments in 3D printers for prototyping are still the most concrete. Here, too, the best way to make the change is to take people on this journey and equip them with further skills. Sometimes it’s simply about supplementing existing knowledge. You will rarely be able to use a designer or a buyer as a software developer. For example in mob programming teams, they can help deliver faster, better quality products. Their requirements and expertise go directly into the product and vice versa they take knowledge about the origin of the product.

Pillars of identity preserved

As in a house that you are renovating, you should look for and keep the load-bearing elements. So long, until the new carries and has replaced the old. These can be people with whom the employees identify themselves, these can be rituals such as a company day, during which employees can get to know each other “privately”. They can be old-fashioned buildings that exude an atmosphere of intimacy.

The transition to Agile is emotional. That’s because people will have to change their mindset. For example, the Product Owner can not give instructions to the Agile Scrum team on how they are going to build a solution. He or she Only can explain What, Why and Who. The Product Owner needs to empower the teams to come with solutions and trust the team that they do. In Design Thinking, brainstorming is about killing your darlings to regain plurality and ideas that best meet customer needs. The change affects all of the values we bring and the experiences we have had in life until then.

Use support specifically

For this reason, external support to help with the Agile transformation can be real valuable. You should get the view from the outside and the knowledge of the possibilities offered by Agile methods on board. A good pilot will tell you what you should focus on and where the runway is to land safe. To say it with different: “For those who do not know the runway, no wind is the right one for them.” Depending on where you are on the journey, practical, operational support can be provided, for example, in method training or as Scrum Master consist. Strategic consulting by Agile transition coaches in an Agile Transition Team (ATT) helps with the implementation on a larger scale.


Agility is interesting for any company, as long as the change happens with a sense of proportion and respect. It is not a formula or business case that can be calculated and returns at a certain time X. It is a constant change to become better and more efficient. But it is a promising path (journey) in a world that is turning to be faster and faster. Properly used, Agility offers the opportunity to combine the best of old and new to act in a fast changing world. Time to Market, being on time is key.


Agile, Posts

The agile method is increasingly referenced, be it in software development or product management, contributing to the appearance that waterfall is a dying method.  It is beneficial to remember, however, that the two methodologies differ in their organization, approaches to projects, and levels of flexibility. These differences make it such that one method may be more effective than the other in certain instances, and vice versa.  
In instances where the transition from waterfall to agile is deemed necessary, though, there are specific considerations and steps that should be taken.  High amongst the considerations to take in making the transition to agile is what can be expected to result, and what cannot. A result that is important to keep in mind is that transitioning to agile will induce chaos initially, but over time – and with the blueprint to success in mind – increased team confidence towards the executive team, amongst other successes, can be observed.

Waterfall Versus Agile Methodologies

The waterfall method is the more traditional of the two.  It consists of a linear approach to product management, in which each of the stages of the product’s development process – analysis, design, implementation, verification, and maintenance – must be completed before moving onto the next stage.  There is little room for changes during the development process, making the waterfall method more rigid than the agile method.

The agile method is newer than the waterfall method, and it is more flexible in terms of allowing teams to adapt to changes quickly and continuously throughout product development.  Although the agile method incorporates the stages that compose the waterfall method, those stages occur multiple times within any given agile product development project. Product development under the agile method consists of multiple cycles, each with the stages of analysis, design, implementation, verification, and maintenance.  The emphasis of this method is on rapid delivery of a relatively complete product, such that feedback can be gleaned and used to inform the next cycle. The feedback from each testing stage is used to make changes to the developing product’s components, thereby enhancing the product and increasing its chances of success amongst its intended users or customers.  Unlike with the waterfall method, each stage need not be thoroughly complete before moving onto the next stage; changes are made as the product development process progresses.

Selecting the Right Waterfall Project
Given the differences between the two methods, there are certain projects for which the waterfall method is more suitable than the agile method.  There are four main project components to consider when deciding whether or not to use the waterfall method, which are technical and business complexity, the business stakeholder, whether or not the project is a web or cloud based solution, and team size.

Technical and Business Complexity
The waterfall method is more suitable for product development projects that possess lower technical and business complexity.  If the product at hand is a technically complex one, then it likely will require copious amounts of user feedback in order to smooth out the details; the waterfall method, in its rigid stages, would not leave much room to test various components on users or to make repeated adjustments to the product.  The waterfall method also is not equipped to handle the rapid changes in technology or expectations that arise with technically complex products. Waterfall is also not efficient in the situation of products changing scopes and budgets.

Business Stakeholder Involvement
Waterfall is suitable if the business stakeholders for the product cannot be extensively involved in the product’s development.  Under the waterfall method, the stakeholders’ requirements for the product are conveyed at the beginning, and because there is little room for alterations throughout the development process, the stakeholders do not need to be consulted throughout the process. In Agile stakeholder needs to work closely with the team, should be able to make quick decisions 

Web or Cloud Based
Waterfall is more efficient with products that are web-based, as opposed to cloud-based ones.  A cloud-based product continuously changes, requiring experienced team members who can address the changes quickly.  The users of cloud-based products have different and evolving skills regarding the product, rendering it impossible to assume their knowledge base – an aspect that is pertinent to planning the product development stages under the waterfall method.
I agree that Cloud based projects, agile is more suited. But we also have lot of web based projects that uses agile, so this point may not fit well. It may more accurate to have a classification as Application Platform/Type and under that say Web or cloud based Agile and Mainframes/Legacy/Backend driven-Waterfall. Agile is more suited for new development work and not for Maintenance kind of work.

Team Size 
When a development team is large, then the waterfall method may be used.  This method works well with large teams, because it is plan-driven and the plan for each project is set at the beginning and is well documented.  Team members do not need to coordinate as closely as with agile – which is difficult to do with large teams – and team members do not have to be extremely experienced in order to work on a product using the waterfall method.  Team members can leave and a new member could replace their work, as they would be able to look through the documents and pick up where the previous team member left off.  

Interfaces and Interdependencies

Waterfall may be the best fit if the system that we develop has more than 3 interfacing applications and has lot of interdependencies with other projects. 


Wherever we have lot of requirements driven by legal/ compliance, waterfall may be the best fit. The more open ended nature, less defined aspects and lack of substantial documentation  inherent to agile may impose challenges to businesses.

For product development projects that are more suitable for agile than waterfall, then the executive and development teams must make a transition.  Though each company’s transition from waterfall to agile will be different, there exist general steps that should be taken by any company making the transition.  First, the company should have a transition plan and timeframe, along with training for everyone in the company. One way to approach training is to begin with the executives, then once they are well-versed in agile, to train other employees.  After training is complete, it is necessary to introduce the new, agile roles within the company, such as the Product Owner and Scrum Master. Once individuals have been trained and roles have been established, it is time to select a pilot project to work on using the agile method.  Along with selecting a pilot project, the company must decide upon the team size and sprint durations, and begin introducing daily meetings.
Given the differences between the waterfall and agile methods, it can be expected that working under the agile method will be chaotic at first, as team members have to adjust to the new roles and routines.  It cannot be expected that the process will be smooth or without glitches. The process will likely constitute trial and error to some extent. It also cannot be expected that the transition will result in an immediate boost in project success.  Some team members might be inclined to want to be told what to do, as they were under the waterfall method, instead of being more self-directed in their work. It might also take time for some individuals to adjust to communicating their work thoroughly to every other team member and to working more collaboratively.
On the positive side, it can be expected that after the initial transition phase, and after some pilot projects have been completed, the teams will adapt to the agile method.  The agile method can be expected to provide lower market risk for the product, due to the many iterations, and better visibility to business stakeholders. Given time and effort, the company will be able to realize the full potential of the agile method.

Benefits of Iterations
The agile method is essentially a variation of the iterative development method.  Core to iterative development is building a product incrementally, beginning with the features that create a complete, though basic product, and then adding on additional features to create a more advanced and complete product.  This system of incrementally building up a product, which is not present in the waterfall method, provides the benefit of allowing improvements to be made on the product throughout its development, as feedback is gleaned from the iterations and is made use of.  Incorporating user feedback into the product helps ensure that the final end product will be more successful than if it had not addressed users’ wants and needs.
Another benefit of iterations is that they help to build team confidence towards the executive team.  In building the product incrementally and adjusting its components as necessary, teams are provided with the opportunity to relay their findings – from user feedback – to the executive team, and make recommendations regarding the product’s components that likely will be implemented.  Delivery of each iteration’s product reduces uncertainty and enhances confidence. The executive team provides more authority to the development teams to adjust and build up the product, which increases team confidence with the executives.  
One other major advantage of iteration would be allowing business to adapt to a change in the market rapidly. A new feature that your competitor has, new technology that is creating buzz in the market can be quickly adapted by reprioritizing what needs to be delivered in an iteration

The Final Blueprint to Success
The transition to agile should be based in a thorough understanding of whether agile is more suitable than waterfall for your company and projects.  If agile is more suitable for your projects, then the transition to agile begins with the committed decision to do so. Commitment to implementing agile is a key factor in making a successful transition.  Though each company’s transition to agile will be different in its details, a successful transition incorporates components of the following blueprint.

Plan and Initiate
Agile transitions should be based on a plan for the transition, including the goals for the initiative.  Once a plan is solidified, it is as important to hold agile trainings for management and trickle the trainings to other teams.

After the agile plan is in place and trainings have been completed, the company’s agile transition will be in full swing.  The kick-off stage of the blueprint is marked by Release planning, backlog refinement, establishing work policies and roles, tools for ALM( Rally, TFS, Excel) and planning the sprints.

This stage is marked by inspection of the company’s work and dynamics under agile, and making changes accordingly. Feedbacks from the teams as well as management through Agile surveys, Scrum masters community helps to establish best practices & standards across teams ant to identify potential issues. Issues should be addressed and smoothed out, while agile development plans should be solidified for each role.  

Reflection of the work from the previous stages should be used to inform changes in the transition to agile.  Amongst the improvements that could be made are focusing on improving agile KPIs, improving meetings, and harnessing agile management. Engaging an agile coach would help an organization on strategizing areas of improvement and transitioning to the next level

The blueprint to agile transitioning is a loose guideline to the process, but it is not a guarantee of quick and smooth success.  Ultimately, the success of your company’s transition from waterfall to agile depends upon the strength of your commitment to the transition, the ability to convince team members about agile, and perseverance towards attaining full agile success.

Agile, Posts

The global pace of change in every industry is faster than it’s ever been.  

Issues and opportunities like new technology, legislative changes, and customer expectations are frequently affecting businesses of all sizes. The ability to adapt to these changes is what makes the difference between a company that is thriving and one that is merely surviving.

According to the Business Agility Institute, business agility is the capacity and willingness of an organization to adapt to, create, and leverage change for their customer’s benefit.

Business agility is about your business’ ability to react swiftly and gracefully to any change. Agile businesses combine speed and stability to pivot effortlessly when the landscape changes.

Businesses who adopt agile practices across their organization consistently outperform their competitors who are still burdened with old ways of thinking and working.

Even better, business agility allows you to challenge and disrupt while your competitors are simply trying to keep up.


How can organizations become agile?


It takes a combination of factors to make a business truly agile, including flexible leadership and technology. Because agility demands that your departments collaborate, becoming an agile business means breaking down silos and aligning goals across departments.

Becoming truly agile can be a challenging but incredibly worthwhile journey. It takes a shift in your strategy, culture, and business structure that allows you to adapt quickly in line with external and internal factors.

The rewards, however, speak for themselves. Businesses who embrace agility experience benefits like faster product delivery time, improved staff engagement, increased revenue, and higher profits.

Business agility is becoming business as usual, is your organization ready?





Agile, Articles, Posts

Hello! We’re Agile!
Agile seemingly is a buzzword, but it is not sufficient to simply adopt or implement agile; for success, it is vital to be agile. 

Those working in an agile environment must expect and embrace changes, for changes are at the heart of this process.  Requirements for the product will change multiple times throughout development, as feedback is gleaned and as circumstances change.  There may also be changes to the development team’s structure as members enter and exit.  Such changes should be prepared for, in order to handle them as smoothly as possible, and with as few consequences for projects as possible.

The journey to being agile begins with the mindset to expect and embrace changes, which assists in handling those changes well when they arise.  It also prevents panic when those changes occur, thereby enabling teams to take control over the situation better as they happen.


Agile is a highly collaborative methodology, in that development members must work closely with one another in order to accelerate each development stage and sprint.  That is key to agile product development.  Development team members must collaborate and coordinate their work to complete each task within the established timeframe.  To be agile, individuals should embrace the frequent interaction amongst those involved in agile product development, within and outside of meetings. 


Not only should they communicate updates and issues related to the project, but they should also communicate suggestions regarding team dynamics, in order to boost agile productivity.  Updates, issues, and suggestions should be communicated frequently in order to generate the necessary actions to improve the agile experience.


Feedback is important to making changes to the agile project and to the teams’ composition, as needed.  It is vital that the development team members provide feedback regarding their work, in order for the remainder of the project to improve, and to enhance upcoming agile projects.  Being agile involves being active in providing feedback.


Another factor important to being agile is the ability to decompose tasks.  Agile product development is all about decomposing a large, complex project into short sprints composed of small stages, in the effort to accelerate and enhance the product development process.  Each sprint’s backlog should be decomposed into small tasks, to make them more manageable and to assist with the speed with which they can be completed.  To be agile is to keep this in mind and to approach anything project related with this mindset.


Using agile methodology is not to be confused with being agile.  To engage in agile is not the same as being agile, but once the agile method is in process, it is not difficult to make the leap to being agile.  Being agile is a mindset that embraces agile factors such as changes, communication, feedback, and decomposition, and approaching more than project work with that mindset.  Once an individual is agile, a boost of productivity will follow.