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.

Conclusion

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.




0

Agile, Posts

 

Agile, applicable to product development across a range of industries, is becoming an increasingly spotlighted methodology – so much so that it may be difficult to fathom not reaping the numerous benefits of agile.  A word of caution must be extended because of the seeming inability to screw up with agile.  It is possible for agile to not result in success, but is also possible to avoid this scenario.


What ensues is the detailing of the top ten ways to avoid screwing up with agile, such that you can be one of those who implements agile successfully and reaps the rewards.


  1. Take team meetings – with everyone included – seriously.

This point cannot be emphasized enough.  It is too easy to be lax with who attends meetings, with the thought that if some or most team members are in attendance, then the information from the meeting will be conveyed to those absent.  This mentality clashes with agile implementation. Despite the repetition of daily meetings and the time invested in them, they are important to successful agile implementation, for meetings allow issues to come up and be addressed, and for everyone to be on the same page regarding progress on the project.


  1. Do not forego the PO role.

It may be tempting to view the Product Owner role as one that can be doubled up, in that the PO could take on development tasks in addition to their PO duties.  The PO, however, should be fully committed to PO duties and only those. The PO has their hands full with handling the requests of stakeholders, conveying the project requirements to the development team, and ensuring that the final product fulfills requirements.  To have the PO take on development work would draw their attention away from these significant duties and potentially tarnish the quality of the project.


  1. Define what “done” entails for your organization, and make sure everyone is on that page.

One development team member’s definition of “done” is different from that of another.  This necessitates that everyone, including the Product Owner and the development team members, is clear on what entails a completed story.  If there are different definitions of “done” floating around, then matters become complicated and work may be hindered, as people continue to adjust the quality of tasks according to their definition of “done” instead of addressing other product issues.  Not having a single definition of “done” also interferes with measuring velocity.  


  1. Estimate stories in relation to other stories, instead of in relation to time.

It is important to measure stories in terms of points, a metric that enables comparison of stories and which is crucial in the measurement of velocity.  Estimating stories in relation to one another – relative estimation – is more effective in agile than estimating the amount of time to complete stories – absolute estimation – as the latter requires consideration of multiple factors, including individual team member differences in productivity, chances that the work goes according to plan, and the time to complete each stage of a cycle.  Agile emphasizes flexibility and relative estimation provides that. It also prevents the team members from rushing their work to fit a time estimate.


  1. The Product Owner should loop in stakeholders consistently throughout development.

This point is related to the PO’s thorough fulfillment of their duties.  Some PO’s may think that it is sufficient to meet with stakeholders to discuss the product’s development merely at the beginning and upon completion of the product.  POs should touch base with business stakeholders throughout the development process, after each sprint is completed. This helps to ensure that the stakeholders will not be unpleasantly surprised upon product completion.


  1. If using agile, be consistent.

Either completely transition to agile or do not, but do not combine some agile components with non-agile practices.  This is detrimental to productivity and the work result. Some may think that it is harmless to adopt some components of agile, while forgoing other parts of it, such as skipping the PO role or having the PO be a mixture of PO and other duties.  This complicates matters and prevents everyone involved from benefitting from the full potential of agile.


  1. Establish clear goals for each sprint.

Not establishing clear goals for each sprint is a sure way to screw up agile.  Agile is more open-ended than other methodologies, but in order for it to work well, there cannot be ambiguity in establishing the goals of each sprint.  Without clear goals, development team members will have issues focusing, and the ambiguity can lead to a lower productivity than if they had clear goals from the get-go.


  1. Product Owners cannot forget that they are one with the development team.

It may be difficult to remember that POs are not management in the traditional sense, but with agile, it is a vital point to have in mind.  POs cannot impose new tasks upon team members, as doing so would interfere with the project at hand – with negative consequences to the project being completed with agile.


  1. Make use of the ability to measure team velocity.

Measuring and knowing your team’s velocity is a relatively simple process that will provide useful information for achieving success with your agile project.  Not measuring velocity hinders the ability to estimate what to establish as sprint goals.


  1. Development team members are not entirely on board with agile – due to a lack of adequate information.

Another way to ensure that the benefits of agile will not be reaped is to skip agile training for development team members.  Agile training is an important factor in swaying team members to accept, and be informed about, agile and the work process that they will soon be a part of.  Without adequate training on agile, team members may not be equipped to fully contribute and may not perform as well as if they were fully knowledgeable about agile and its benefits.


Summary

Agile is not a magic bullet method, despite its numerous advantages and its vast potential to boost product development.  If the above ten aspects are not taken into play, then it is possible that your agile implementation will not yield the full potential of agile.  On a positive note, following the ten points is relatively simple and will help to ensure that your agile efforts are met with success.

0

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
Waterfall

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.

Agile
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. 


Legal/Compliance

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.

Transitioning
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.

Kick-Off
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.


Stabilize
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.  


Improve
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


Summary
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.
0

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?

 

 

 

0

Agile, General, Posts

Introduction of what a Scrum Team is, what do they do, how they do it, dynamics, forming, norming…

 

Hello!  We Are a Scrum Team
Scrum teams are many things – productive, agile, self-organized, and, if the formation is approached properly, successful.  What are the components of a successful scrum team?  How can scrum team members contribute to a successful one?

 

Roles
There are three roles in scrum teams – the Product Owner, Scrum Master, and development team members.  The Product Owner, or PO, is the communicator between a scrum project’s business stakeholders and development teams.  The PO is responsible for conveying the project’s requirements to the team, and project updates to the business stakeholders.  The Scrum Master is the team’s caretaker and “slave” to the PO, in that the Scrum Master handles any issue that may impede the development team’s work, and they report updates to the PO and further communicate the PO’s project requirements.  The development team members, the role with the most members in a scrum team, are responsible for completing the sprints and creating a product that meets the project’s requirements.

 

Dynamics
Each scrum team must work closely together to complete scrum projects successfully.  Key to a successful scrum project is a close-knit scrum team with good dynamics amongst its members.  This is especially important given that scrum teams self-organize themselves in each sprint, in relation to who takes on which tasks.

 

Expectations of Each Member
In order to meet the responsibilities of their role, scrum development team members are expected to self-organize amongst themselves, in regards to who takes on which task in each sprint.  They must figure out whose strengths relate to each task, and work out how to achieve the project’s goals.  The Scrum Master is expected to be attentive to the development team, whether that entails adjusting a broken work table – which impedes project work – or assisting team members in working out issues that impede their work.  The PO must be attentive to the work progress and ensure that they understand what is going well and not for the development team.  The PO is expected to also keep business stakeholders updated and to ensure that business stakeholders’ requirements are parlayed to the team and met.

Given the closeness required of scrum teams in order to succeed in applying scrum to projects, team members will have expectations that go beyond those of their specific roles.  Everyone involved should communicate often, attend daily scrum meetings, parlay any issues as soon as possible, and be open to changes.

 

Summary
Scrum teams can be highly productive and successful, in terms of their project work, if those involved understand their roles and expectations, and take those seriously.  Each scrum team member is a contributor whose actions affect the entire team – and the team’s work result.  It is important for the success of the team that everyone involved keeps that in mind.

 

Have you also read what an Agile team does to be Agile? Read here!

 

 

0

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. 

Changes
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.

 

Communication
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
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.

 

Decompose
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.

 

Summary
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.


1