Staying lean!
Posted by Marcel Offermans in Uncategorized on October 21st, 2009
A while ago I posted here about the role of the architect when building lean software. Inspired by posts by Kirk, Hal and Joel, I’d like to build a case for selecting the right tools and frameworks in order to be able to sustain your agility in the long run.
Starting with the opening argument that Hal makes, we’ve all been in projects for long amounts of time, where at one point you start wondering what became of that once beautiful and comprehensible design, or those fast build and test cycles you started out with. As products evolve over time, they all seem to loose a lot of their initial “elegance” up to the point where people seriously start considering starting from scratch “because it’s easier than bolting on new features to the existing product”. Apart from the fact that that is very counter-productive from the point of view of the customer, you’re also throwing away a lot of experience, especially if the original authors of that code are no longer around (which sometimes is stated as a reason to start over). Joel made a case for not starting from scratch and raises some very valid points there.
So, if it’s not smart to start from scratch, and you really want to sustain that agility, how are you going to make that happen? There, going back to one of the points that Kirk makes, a lot depends on your architecture, especially if you look at it from his point of view:
The goal of architecture is to minimize the impact and cost of change. To do this requires we create flexible systems with the ability to adapt and evolve. But with flexibility comes complexity, presenting architects with a paradox. As we design more adaptable systems, the additional complexity reduces their ability to survive. Eventually, the software rots, the architecture crumbles, and the system fails. Therefore, we must find a way to increase adaptability without decreasing survivability.
Combining observations here it becomes increasingly important to stay modular and to really try hard to loosely couple your components because that has tremendous benefits in the long run. Doing that is not easy though, as it requires a lot of thought, and you might need to make some other trade-offs in favor of modularity and loose coupling. However, it is one of the few ways that allow you to make decisions that are always reversible, as ripping out a single component in an environment where there are as little dependencies as possible and where each of these dependencies have small and substitutable interfaces remains as easy as it was when you started the project. In practice it also means that it is worthwhile ensuring that these qualities in the overall architecture do not deteriorate and that you spend enough time making sure they don’t by refactoring and reviewing code as part of the normal development cycle.
Scrum at University
Posted by Wout Lemmens in Development Process, scrum on August 28th, 2009
A lot of companies are currently developing software in an agile way. Quite often universities stay behind in technologies and methodologies that are taught with respect to what’s hot in the working field. Luckily quite some universities do try to keep up with the ‘real world’, and try to deliver graduates with up-to-date knowledge that fits the needs of companies.
At Avans University of Applied Sciences in ’s Hertogenbosch, the project ‘Game Design’ was started, and the idea was to apply an agile development process to introduce this to the students as well. This project had a duration of about 14 weeks, fixed six-person teams, and quite some availability of all team members each week. Besides that, the lecturers were willing to play the role of Product Owner, preventing the students from creating whatever they liked. Good starting point of a project to apply Scrum to.
And as luminis has quite some experience in applying Scrum at various client projects, I was asked to give a lecture on the Scrum basics, and share some of our experiences.
Just before the summer holiday the project was finished, and the following experiences were the result:
- Applying Scrum was quite hard in the beginning. They didn’t meet every day, and especially in the beginning they were working on large tasks like the design document and getting familar with technologies. It was difficult to split that up into smaller pieces.
- In the second part of the project (more focused on implementation), the students were able to apply Scrum in a better way. Even though they didn’t meet at a daily basis, they were able to make well estimated tasks, and execute these in a one-week sprint. This provided a clear overview of the project and the progress. And the detailed planning worked out great.
Concluding: as an introduction to Scrum, it wasn’t a real success applying it in the first phase of the project (sprint 0 type of work). For the students it felt quite artificial, and they did not experience any benefits. On the other hand, looking at the second phase (implementation) of the project it was a success as they really experienced the usefulness of practices like detailed planning and weekly deliveries.
Result; the invitation for next years ‘Games’ project already stands.
The right people are not afraid
Posted by Angelo van der Sijpt in Development Process on August 23rd, 2009
Quite some time ago, I read Jaibeer Malik’s excellent writeup on the right kind of people for staffing you agile project. I totally agree with his analysis that you need people that are “willing to make it happen”.
The right kind of people for your project have another trait in common: they are not afraid. What is there to be afraid of?
- Change It is in the nature of people to prefer it when things stay the same. Yet, change is the lifeblood of agile processes: we changed to get agile, we update our own process, and just when you think we figured it out, we change again. Better get used to it.
- Failure As John Holt wrote in Celebrate your mistakes, “If you’re not making mistakes, you’re not taking risks, and that means you’re not going anywhere. The key is to make mistakes faster than the competition, so you have more changes to learn and win.” Sure, failing is no fun, but fearing it will freeze you, making sure you can never make things happen.
- Visibility Tying into failure, visibility is about showing what you do. People tend to be very protective about “their job”, which they know bloody well how to do, thank you very much. Still, the open communication in an agile project forces us all to show what we’re doing, every minute we’re working on the project. I think it’s inexcusable to say “Well, I’m working on it now, so just come back tomorrow, and I’ll show you then”. Just show me now, I understand that not everything is OK yet; I would be surprised if it was OK, and you were still spending time on it.
The Agile Manifesto contains the same elements of collaboration, change and interaction. These can, indeed, be kind of intimidating when you are used to signing of work to be done, working under someone else’s responsibility, and consider yourself an expert. Then again, remember that we’re in this together, as a a team. Stop being afraid, and start making things happen!
Recent Comments