Posted by Niklas Odding mid-morning: January 18th, 2011
This blog is intended to be the first of a series of blogs in which I will examine the role of architects in Scrum. I will start with what I think that are the forgotten questions of Scrum and in next blogs I will examine how the role of the architect changes, what kind of architects are needed and and which activities architects should be doing to be successful and valuable.
The forgotten questions of Scrum
In the 1960’s Alfred Chandler already wrote that the organization structure of an organization is tightly related to its strategy and based on its organizational processes. In the optimal world according to Chandler: Structure follows processes follows strategy. (more…)
Posted by Geert Bossuyt at around evening time: January 17th, 2011
Just like the Agile Manifesto was a shock 10 years ago, the MoreAgile Manifesto creates some shock effects now.
Responsibility is scary, Business value is undefined, partnership feels impossible and change is kind of accepted but not loved.
- Over the next coming years expert professionals will become very rare, so employers will have to make the difference by creating the best possible workplace. Part of this will be that responsibility embraces empowerment and that the freedom that comes with this will be the only thing wanted by this professionals.
- Business Value is already important today, however difficult to measure. The Lean and SixSigma movements are creating a setting where not measuring value is not done. This expertise will be the a good basis to use as a logical measurement tool for success in software delivery.
- Endusers are rapidly maturing into strong groups with an opinion that matters. Social media will help them to raise their voice. Service companies and software suppliers will have no other option but to deliver services in partnership to catch up with the high demands from the market.
- The speed of change will go up for another couple of decades. Sprints of 2 weeks are far to long, waiting to see something in production that is already finished will no longer be accepted. Just responding to change will simply not be enough. We have to love change.
It took us 10 years to create a world where the ideas of the Agile Manifesto are accepted and commonly used. Likewise, MoreAgile is not something we will easily achieve. The ideas are bolt and a lot of things need to change before we can really work MoreAgile.
Posted by Geert Bossuyt around lunchtime: December 23rd, 2010
We encounter possibilities to focus more on effectiveness by working Agile and learning from that. Based upon our experience we value :
Teamwork & responsibility over Individuals and Interaction
Deliver Value over Working software
Partnership elaboration over Customer collaboration
Embrace change over Respond to Change
While we value the Agile Manifesto, we state that MoreAgile is more Agile.
Posted by Jarl Meijer just before lunchtime: December 13th, 2010
The transition to the Agile way of working is more than a process change. It requires a different way of interaction and behavior and a different mindset. In a large (a little less than 200 people) Agile Implementation endeavor we organized an Agile Mindset session to explain Agile principles and to push the Agile teams away from the comfort of their traditional patterns.
Getting on the Agile track successfully… (more…)
Posted by Geert Bossuyt around lunchtime: September 30th, 2010
The tester is a member of a Scrum team. This is a different mindset from the traditional views on testers in software development. The agile tester focuses on delivering value instead of on testing. The agile tester is responsible for delivering what the business needs instead of just finding bugs. Most importantly: the agile tester is not responsible for testing!
Recently I published an article on testing in a Scrum team for the Eurostar 2010 newsletters. It’s about the mindset of an Agile tester. This blog post summarizes the core of that article.
Posted by Geert Bossuyt just before lunchtime: September 24th, 2010
For many of us ‘Inspect & Adapt’ has become a second nature. We love to timebox because we need the feedback to learn from it. ‘Feedback’ about the system we’re building or the process we’re using. Because individuals are to be found more important than processes and tools, we must not forget to give each other good feedback so we can also learn from that. After all, the Team will never grow, if the individuals in the Team don’t grow.
To give good one-on-one feedback is a very difficult thing. It’s hard to keep it save and it’s even harder to do it in a way that really helps the other learning something from it.
I ran into some nice ways of giving feedback :
Posted by Marco Mulder just before lunchtime: September 9th, 2010
In this blog, I make a case for what I think is the next step in the evolution of Agile project management. The focus of project management used to be based on managing Tasks that people perform to deliver a piece of software. Agile project management shifted focus to managing the delivery of Features. I believe that the time is ripe for the Agile community to take the next step: move towards Value driven project management.
(more…)
Posted by Marnix van Wendel de Joode in the early afternoon: September 2nd, 2010
In Agile, everyone agrees on the concept that continuous improvement is a good thing. In Scrum and also in most Kanban practices we even have a ceremony to support this, namely The Retrospective. This periodically occurring meeting (often every other week) with the entire team plays a vital part in the process and in team dynamics.
In most retrospectives, focus is on improvement. Questions are asked like ‘What is going wrong or could be done better?’, ‘What can we do to improve things?’, ‘Did we actually improve?’. While there is real value in these questions (and they should definitely should be asked), there is another part of a retrospective that is also very important: The Good Things.
Posted by Rik de Groot around lunchtime: August 20th, 2010
Planning has an important role in Agile. The team uses planning to estimate the complexity of a requirement (userstory). The number of complexity points handled in previous timeframes then helps to decide what could fit into the next timeframe. However the complexity changes in time. Things get easier doing it a second time or easier ways are found for problems. This makes the planning even harder. Creating a reference base might bring stability in planning. These references make it possible to create a release planning without planning all the requirements upfront.
Posted by Sander van den Berg in the early evening: August 11th, 2010
Over the last 4 month’s we have written a series of blogposts describing 11 principles of Lean Architecture. This post will be the last of the series, the wrap up post.