Jump to content
Search In
  • More options...
Find results that contain...
Find results in...

[Article] Agile 2 is here - the new iteration of Agile

Jimi Wikman

Recommended Posts

  • Owner

Agile 2 is here. It has been in the works for a while and from what I can tell there has been some sharp and experienced minds involved in that work. It is in many ways a retrospective, but also a way to look at the great failure that is Agile. A failure that originates in the division of visions and the ideal becoming absolutes. Agile 2 hope to change that and it is a great ambition that have my wholehearted support.

In the case for Agile 2 the statement is that one of the issues with the original is that it lack the inclusion of leadership. I agree with that as well as to note that the developers do not always enjoy what is referred as Agile in many organizations. The fracture of the Agile community and then the stagnation into a fixed perception almost to the point of worship also resonate with me.


Large organizations that tried to use Agile – the word quickly became a noun – often failed. This was no surprise because early Agile was about individual teams, but a large organization is far more complex than a single team. Everyone expected that over time, consensus would emerge for how to use Agile methods at scale, but instead, the community continued to splinter. Today, organizations that want to use Agile methods at scale are stuck choosing one of several competing and divergent approaches.

This is by far the most common experience for me when meeting with organizations. A will to move towards Agile, but a methodology that is fixed in its ways and lack the component of leadership and steering. I also find the interpretation of Agile to be heavily reduced when facing the opposition of reality, leading to an ad hoc situation that is damaging and frustrating to the people involved.

At first glance Agile 2 seem to be on the right track. I look forward to seeing where this will go and how it will challenge today's Agile community. Hopefully the Agile community will adopt their own methodology and embrace this new input to evolve their way of working.

I support the work of Agile 2 and I hope you do too.





View full blog article

Link to comment
Share on other sites

  • Replies 0
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Similar Content

    • By Jimi Wikman
      My assignment was to make a new design for the web based user area based on the graphical profile from one of ChessIT's clients. The design had to be light in terms of changes as the project had hard deadlines. I worked with the client and the developers to find a balance between the two that satisfied the requirements and respected the time constraints.
    • By Jimi Wikman
      My assignment was to review and build a new work process with JIRA & Confluence as tools for the development efforts at Axfood. Based on the SAFE agile process with practical experience in making projects actually become a reality I built a process that was custom-made for Axfood and their specific challenges.
    • By Jimi Wikman
      Jira tool manager with the task of stabilizing the system and setting up work processes for all teams within H&M. Responsible for several projects including cloud initiatives and coordination with other systems such as ServiceNow. Heavily involved in designing the build processes (requirements, development, design, deploy and test) for the process office. Responsible for the design and implementation of SAFe in Jira and the build processes. Responsible for a small team of Atlassian experts. Supported 400+ teams with Jira questions and training of work processes.
    • By Jimi Wikman
      Satire focused on Scrum and its many quirky ways to mess up how it should work 🙂
    • By Jimi Wikman
      Product owners often get blamed for not understanding Agile and for not providing clear requirements. Is this their fault though, or are you not providing the correct feedback to help them improve? Agile teams often work with the product owner absent, especially in the retrospectives. If that is true for your team, who is actually at fault then?
      I hear this all the time. "The product owner" is absent or "the product owner can't give a straight answer on what I should do, it changes by the minute". This is especially prominent in project based organizations where Agile means that you just remove the requirements phase in your waterfall process to make things fall down to the development team faster. Agile becomes ad-hoc and chaotic and it is all the product owners fault. Right?
      This is a problematic attitude and one that to me clearly means that the team is not really Agile, but still work as a receiver instead of the engine it should be. Although in most organizations there are two processes and the development team always is the receiver of strategic goals, they should not be a passive one.
      Not being passive means that you put demands on what you receive.
      How you receive a new business need, what information you need and how you work together with the product owner is not something that you passively sit around and complain about. It is the core of what the retrospectives are for! I would bet that in most teams where you have issues with the product owner you do not include that person in your retrospectives? Do you even provide feedback or set up activities to help the product owner improve together with you?
      If the product owner is not included, then could the issue be with you and not the product owner?
      The product owner is a part of your team. This means that you are responsible to speak up and ensure that everyone in the team is working in the way that best benefit the team. This means that you should provide feedback if the product owner is absent or if you do not get the information you need. This should be done in retrospective, just like you do it with every other feedback concerning your work process and collaboration in the team.
      Easy to say, but our Product Owner does not care.
      I know, this happens all the time. The product owner is tied up in meetings all day and just ignore your feedback. This is where you need to play hardball and provide empiric evidence that the issues you have is not your fault and that you have done your job to try to improve this. The First step is to go above the product owner and point out the issue to the people above. Sometimes that works, but it may not always be an option.
      In the sprint planning you should be very clear on what information need to be present for you to accept a user story. Remember that once you put the user story in the sprint, you have accepted the user story and you are responsible for the consequence for poor requirements. Never accept a user story that is not clear enough for you to work on. It is the responsibility of the product owner to ensure the user story can be accepted by the development team.
      If you use Jira then your next step will be to push back everything that is unclear to the product owner. This is done by assigning the product owner to the issue, put the issue in blocked status, or flag the issue if you do not have a blocked status and then comment saying that you wait for the product owner to respond. Once done, leave the issue and move to another issue. This will effectively remove the priority for the first issue as it will now be done after whatever issue you pickup next.
      This will allow you to move responsibility to the product owner and point out the issues you are having. It also allows you to get statistics on waiting times the team have due to the product owner not doing their job.
      Failure is on the team, not the product owner alone
      Just as the entire team is at fault if the scrum master or a team member is dragging the team down, the same goes for product owners. You manage it through the retrospective and constructive feedback. Help the product owner to be the team member you need hem to be. If that fail, then you as a team will fail as well.
      Make demands, just as you would for any other team member. Make sure their calendar have all stand ups booked, all retrospectives should be holy times and if they run around for meetings all the time, have them block time in their calendar for the team. You would not accept a developer to not do their job, so don't accept if the product owner is not doing theirs either.
      At the end of the day, remember that no product owner want to be a bad one. They often get dragged into activities where their role is poorly defined, so they need help to define what you as a team demand of them. This will make it more clear to them how to prioritize their time, or find a replacement to make sure you get the team member you deserve and need.
      Never sit silent with a clenched fist in your pocket.
      Speak up and offer constructive solutions and you will be surprised how willing many are to solve the situation with you. Teams work together and since we still have not developed telepathy we need to verbally communicate and express our need to work better together.
      Product owners are not outsiders, they are valued team members.
      ...or at least they should be.

  • Create New...