Agila Sverige is a wrap. It has been two exiting days with a lot of great presentations and interesting topics discussed at the Open X sessions.The slides from my presentation can be found here: Arkitektrollen – Agila Sverige 2012 (text is in Swedish).
If you want more information about The Agile Architect Pattern, see my previous post about it here at this site.
Guide the team to reduce technical debt before it becomes a problem.
The nature of agile development is to deliver working software continuously. This means that the focus for all actors (Product Owner, Scrum Master and Team) is on the functionality delivered in each iteration. As a consequence, technical debt is considered okay and is likely to increase for each iteration completed. Often, this is allowed to go on until the debt has reached a level where the velocity of the team is starting to decline. After a while something has to be done, and the term Refactoring Sprint is introduced. A refactoring sprint is in this context an iteration totally devoted to paying off technical debt, thus no functionality is delivered for an entire iteration.
The Agile Architect Pattern prevents the scenario from the motivating example from happening by introducing an Agile Architect role. The Agile Architect can be seen both as a member of the team and as well as a stakeholder. This makes him/her able to both work with the team members, guiding them while trying to identify architectural issues as well as discussing requirements for future iterations with the technical resources from the client. While the team has a iteration-by-iteration time frame, the agile architect can see a few iterations ahead making sure the architectures evolves in a way that (hopefully) will not cause major problems ahead.
The Agile Architect Pattern should be used in any project spanning over enough iterations likely to cause the technical debt large enough to slow the team down. It is important that the Agile Architect is comfortable both in the code domain acting as a guide for the team as well as on a higher level of abstraction to be able to interact with the client technical resources.
I will be giving a lightning talk on the subject “The Architect role is needed, even in agile projects!” at the Agila Sverige conference which is arranged in Stockholm the 23rd and 24th of April this year. I will not reveal too much of the content here, but as the title implies, I will be promoting the need of an Agile Architect in every project. Agile or not…
I have touched this topic in at least two previous blog posts (Agile Architect and Agilists and Architects), but I seem to be getting into these kind of discussions on a pretty regular basis.
The main area of conflict or misunderstanding is usually around how to create a common architecture or framework (…ouch…) for the entire organization. Most managers and old school dinosaur architects seem to believe that this is best done in long meetings and by producing endless powerpoint presentations and documents containing every buzz word in the world.
I can not stress enough the importance of building an architecture from something that already has been proven to work. And to be able to do that, you as an architect have to get your hands dirty doing some actual coding. An architecture should always be communicated through code, not by slideware!
Even if you are using Scrum or any other development model, agile or not, it is always good practice to have a short status meeting with your team every day. Usually the best time for such a meeting is in the beginning of the day as it gives the team the chance to resolve any issues the same day. Having the meeting in the afternoon implies that any issues probably have to wait until next morning, which is usually not a good thing.
So far, nothing new. The practice of a short stand-up synchronization meeting is pretty well established and non-disputed.
What if you have a team that is distributed not only in distance, but also over different time zones?
Which time zone should be used as basis for determining when to have the meeting? Usually the project it ends up being run by the project manager’s (*) watch. That means that the team in the other end probably will have the meeting in the afternoon. A pretty usual distributed team setup in Europe nowadays are something like this:
Europe: Project manager, architect, test manager
Offshore (China or India): Lead developer, developers, testers
That means that the largest part of the team, the team that actually are doing most of the work are having the daily scrum at a less optimal time of the day than the project management. I think that to really succeed with distributed agile development, you have to let the team decide how to work even if this implies awkwardly timed daily scrums for the project management. Of course, this applies to other aspects of the development process as well.
(*) …or Scrum Master if you prefer…
One of the new words buzzing around in the software industry these days is Kanban. Most people have heard of, or is using, some variant of Scrum or ScrumButt, but Kanban is still pretty new. Henrik Kniberg has written a great article where he compares Kanban and Scrum: Kanban vs Scrum – a practical guide.
In short, Kanban is the Less-is-more cousin of Scrum.
Kanban prescribes only three constraints:
The rest is up to you. Kanban does not exclude Scrum or vice versa. Read the article, inspect and adapt and find what is best for you and your organization.
Most agile methodologies does not mention anything about the role of the architect. The team is supposed to be self-managed and take care of everything, including architecture.
“Big Design Upfront is to be avoided at all costs!”
But what about technical debt? Wouldn’t it be nice if someone had the big picture? Someone who knows the key technologies and standards to use and makes sure that central mechanisms such as error handling are handled conformly?
This has always been some of the focus areas of a software architect. But how does an agile architect differ from a “traditional” one?
In my view, the traditional, high-tower, ivory architect is long dead anyway, so the role of an agile architect is just the same as that of any architect independent of what kind of development methodology that is being used – agile or not. You have to be pragmatic, know the technologies used, be able to communicate through code with developers (no-one likes PowerPoint anyway…) as well as being close to the business stakeholders.
In the post The Decline and Fall of Agile, James Shore highlights some of the problems with introducing agile methodologies.
“Scrum is popular because it’s easy–and that’s part of the problem.”
It is a great blog post, and I am sure that you will feel familiar with the descriptions if you have been applying Scrum or other agile methodologies in real life. I certainly do!
In an earlier post, I wrote about ScrumWorks. After having used it on a couple of projects I have gathered some thoughts here.
I usually prefer the good old whiteboard with post-its or an Excel sheet to track progress and generate burndown charts. But ScrumWorks has proved to be an excellent alternative to these old techniques. Developers find it pretty easy to use, and ScrumMasters get a pleasent user interface and a nice burndown chart almost for free.
So what is the downside? Well, sooner or later you will be asked by management to report progress. And managers are usually not willing (or capable) to using any unfamiliar tools, so you end up exporting the data to make some burndown chart or excel sheet available for them. This type of status reporting is overhead (or waste in lean terminology) and boring.
Luckily, ScrumWorks has a decent Web Services API which makes it fairly easy to extract the information you want. For example generate live burndown charts automatically on a wiki, or use the task information in ScrumWork to verify valid commit comments in a Subversion hook script. Imagination is the only limit…
Ever heard “We’re doing Scrum, but…”?
According to Jeff Sutherland at Øredev 2008, great Scrum teams can boost revenue by 400%. With ScrumButt you are limited to 0-35%. When are we going to understand that Scrum is just a set of simple rules and common sense and not a buffet to choose elements from….?