Posted by Niklas Odding mid-morning: February 9th, 2011
In my last post I stated that there is a lot of emphasis on the fact that architects have to help to get the scrum team to work better, faster en with more quality. By following the agile values the architect will help “strengthening the heartbeat” of the scrum teams. However the activities of architects should encompass more. In this blog I will explain what this is and how to incorporate this in your way of working with scrum teams.
Posted by Niklas Odding around lunchtime: January 26th, 2011
This blog is the second of a series of blogs in which I will examine the role of architects in Scrum. Last week I started with the forgotten questions of Scrum. In this blog I will look in more detail to the Agile Manifesto and the agile values.
Architects and the agile values
Most of the literature concerning the role of architects in an agile context focuses on the Agile flow itself and how architects can avoid disturbing that flow. Mike Cohn, in his book “succeeding with agile” makes the distinction between coding & non-coding architects. In where he states that the coding architects will have less trouble finding their new role in de Agile development process.
An architect within a team has to be able to code himself. He is a team member, who has more experience in structuring the application being build compared to other team members. By using that experience he can add value to the team. Scrum has no particular role for non-coding architects. The question rises if this is totally true. (more…)
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 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 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 Marco Mulder in the early morning: May 15th, 2010
In my experience as a Scrum trainer and coach, I have seen too many Scrum teams that fail to do what Scrum was invented for: Inspect and Adapt.
Do the following statements describe the situation of your team?
- Little is done about problems discussed in Retrospectives.
- Sprint Reviews have no impact on what is build in subsequent sprints.
If so, you may be interested to read my article on the Scrum Alliance website: Effective Retrospectives & Reviews.
Posted by Jarl Meijer at around evening time: April 12th, 2010
Within an Agile project environment periodic demo`s are one of the main strongholds. Demo`s are good for the team and the customers. They set focus and make progress painfully transparent. Agile promotes demoing the teams results every iteration, so every 2-4 weeks, and from the first iteration on. In this article we will present 2 real life cases, and discuss some considerations one should take into account to prevent early demo`s to have a boomerang effect on the project. Early demo`s can set the customers expectations to unrealistic levels which will lead to frustration all around. (more…)
Posted by Serge Beaumont terribly early in the morning: April 1st, 2010
If you write user stories, it is very likely that you have been using the “As a… I want… So That…” stanza. What you might also have found is that it is hard to fill the “So That” clause with something that makes sense. “As A User I Want a button So That I can go to the next screen”… that is pretty naff, isn’t it? So how do you fix it? Ask “Why” several times!
(more…)
Posted by Serge Beaumont mid-afternoon: March 24th, 2010
What does it mean when a Scrum team “commits to a Sprint”? There is a subtlety in the English language that leads to misinterpretation and misuse of the verb “to commit”. I have seen too many cases where a team is held accountable (“bad team, bad!”) because they did not achieve their Sprint goal in some way. And it will be accompanied by the accusation: “…but you committed to the Sprint, didn’t you?”. As a coach, this is the moment I step in to explain what “to commit” really means, and that you want to fail every now and then: succeeding every time is a failure mode all of its own.
(more…)
Posted by Marco Mulder in the late evening: November 25th, 2009
In my previous blog, I talked about when to estimate user stories so that a Product Owner can do release planning based on velocity and relative estimates. This time, I will discuss another topic that I see many Scrum teams struggle with: how to implement improvements based on what is discussed in retrospectives.
Many Scrum teams have a hard time to continuously improve themselves. In retrospectives, problems and possible improvements are discussed. Then nothing happens. In later retrospectives, the same problems are discussed without noticeable changes. Retrospectives like this are a waste of time. Even worse, missing out on the opportunity to continuously improve is a big waste in itself. The velocity of such teams and the quality of their deliverables will almost certainly get better if they find ways to act on improvements that are identified in retrospectives.
(more…)