2-Pizza Team

Listening to another great hanselminute podcast Scott mentioned a concept used at amazon called the 2-Pizza Team. It is a a team where the team size is no larger than 2 pizzas can feed. It turns out that the essence of it is to have a team of the right size to facilitate communication within the team.

At a recent Technology Briefing at ThoughtWorks an example was given of a company where they had made a plan to go down an agile approach and as a result all but one of the original development team are with the company today. I guess in this case either the individuals didn’t want to change or alternatively they didn’t have the personal traits to work in an agile team. The type of individual on a team is a major contributing factor to the success on an agile project.

Could we use the pizza for more than just a measure of the size of a team but also the quality of the individual. Do you want someone who works back every night so needs to be allocated a piece of pizza. Does the type of pizza that a person eats indicate the type of team member they are,  you definitely wouldn’t have a team where only one individual like anchovies, it would just cause tension.

Oh the humble pizza have we underestimated the value of this culinary delight?

The role of the Architect in Agile Projects

When working on an agile project there are four principals from the Agile Manifesto that should focus the project/team. When considering the role of the Architect in the project you still have to conform to these principals. Traditional Architect engagements are at the start of the project with an exit usually shortly after the high level design is complete and some evidence of the implementation of this design has been reviewed.

There is a great article on The Shiny New Agile Architect that caught my eye and does a great job of explaining the responsibilities of the Architect. Much the same as for any project, that is run under any methodology, the Architect is focused on the impact the Non-Functional Requirements have on the final solution. Vikas Hazrati does a great job of distilling this down to some great traits.

The trait about architects building tests to test the architecture decisions is a very interesting one.

An Agile Architect writes system-level tests that stress the architecture.

Unit testing is a major component of any successful agile project it allows the team to respond to change in a controlled manner. Knowing that you can change your code and know that any functionality that you had previously been built still works is a powerful thing. Being able to make changes and know that your architecture still meets your non-functional requirements is even more powerful. Non-functional requirements are all about the quality of the software, having this baked in at the start through testing means it isn’t neglected. Retrofitting a design to deal with a quality issues is never an enjoyable experience.

The prioritisation of features/stories etc in an agile project is the job of the customer so often it is unclear how to build in the non-functional features/stories into the project. A customer should be able to prioritise tasks related to the implementation of non-functional requirements if they are expressed in business value terms. If you can express these requirements in business value terms then the business should be able to priorities them. The important thing here is to capture the dependencies between the functional and the non-functional requirements so that the business realise the impact of developing a quality requirement in the later stages of the project.

Yes the role of the Architect in an Agile project is very different to waterfall projects and the people who succeed in a waterfall project won’t necessarily succeed in an Agile project. I think the key point in the article is that there is still a need for an Architect it just comes down to effectively executing the role within the principals defined in the Agile Manifesto.

FDD on Software Engineering Radio

I posted last year about a project where we got Jeff DeLuca in where we were doing Colour Modelling and FDD. Well Episode 83 of Software Engineering Radion is with Jeff DeLuca the creator of Feature Driven development. A real good synopsis of what FDD is and just as importantly what it isn’t. Something Jeff emphasised several time is that FDD and all agile methodologies for that matter focus on the people aspect which is something I picked up when I worked with FDD.

So what is Colour Modelling

Over the last couple of weeks I have learnt to Colour Model, which introduces some interesting concepts to modelling that you don’t get from Black and White UML. Peter Coad and specifically his book on Color Modelling created the concept. On Peter Coad’s web site the first chapter of his book is available as a download which introduces it well.

At the core of Colour Modelling are four archetypes that allow classes to be categorised. The four archetypes types are:

Moment Interval (Pink) – It represents something that one needs to work with and track for business or legal reasons, something that occurs at a moment in time or over an interval of time.

Role (Yellow) – a role is a way of participation by a party (person or organization), place, or thing.

Description (Blue) -  it is a catalog-entry-like description e.g. a lookup table.

Party,Place,or Thing (Green) – A party, place, or thing is some-one or something who plays different roles.

By categorising your classes in this way you have to ask some interesting questions about the business process (pinks), who (yellow) is involved in the processes and what role (yellow) do they perform. Then there are the descriptions (blue) of all of the above.

Out of this came the Archetypal Domain Shape which firstly show how these shapes generally hang together but also the type of attributes and behaviors you would expect them to have. It provides a good way to figure out what things are and secondly pick up attributes or behaviours that may have been missed.

In the book Java Modeling In Color With UML Peter then goes into typical shapes that you would expect to see for different problem spaces. A good example of this is the parent-child type pattern you would expect to see with some thing like an order and order-details type relationship.

I read the book but it wasn’t until I got into modelling a system that I got to appreciate the beauty that is colour modelling. Colour modelling when we did our modelling exercise with the business on our project was a great communication tool allowing a clear and concise definition of the scope of the project.

Disclaimer: I am from Australia so Colour is spelt with a ‘u’.

Colour Modelling

I have just spent two weeks locked away with two domain experts (users) and a team of ‘L’ plate modelers (myself included), modelling an application that we are about to start building. We got in Jeff De Luca of Feature Driven Development fame to teach and guide us in a process called colour modelling. We started with a two day training course in colour modelling and then we were into it. For two whole weeks building up our understanding of the system and capturing it in models using colours that represent the various archetypes.

The team went through all the highs and lows that characterise the development of a team, so coming out of this we ended up with a strong team of people. The team also now owned the resulting model of the application that had been built up, there is now a history there, blood had almost spilt over names of things and it had all been redrawn a couple of times, changing what was there wouldn’t be done without a fight.

The exercise of building the model revolved around the users walking us through small areas of the process that we then produced a model for. Requirements and use-case documents that had been written were there for reference but the user was the primary source of truth.

One thing I hate about any requirements document is that there is always interpretation involved when designing the system that will meet these requirements. It kills me when the users come back and point to a line in the requirements and explain how this means you should have actually built something completely different to what you had assumed. When we were modelling because of the way we are capturing the requirements in the model, things are very explicit, so there is only one interpretation. On more than one occasion the users would make a comment that contradicted something we had previously modeled and we knew at that point that they had changed the requirements and could seek clarification from them there and then.

Getting so much of the users time (2 weeks) seemed like a tall order before we started this but we ended up with almost 100% of their time during this two weeks which was great. Having the users there was vital as previous understanding that were captured in the requirements document got tested as part of each walk-through. The users as much as the modelers were challenged because there was nowhere to hide and in the early stages there was some rethinking that had to go on but they quickly realised what was required of them, so came prepared.

Out of this two weeks we have a model, yes but we have so much more than that. Agile promotes “Business people and developers must work together…” which for one reason or another is easier said than done but this process of modelling gave us that understanding between the technology team and the business. The team that built the model has an intimate understanding of the domain from a business perspective and from an implementation perspective. Best of all we have a core group who are a performing team!

The next question is how do we repeat this process for other projects, Jeff brought so much to the team, it just won’t be as simple as following the process.

When is it not refactoring

One concept that seems to be abused is that of refactoring, when used correctly it is a fantastic way of making changes to your code while managing the impact the change has on other parts of the system. I came across a post on Martin Fowler’s site where due to some similar discussions on the subject it has led to some boundary cases being identified.

Lava Lamps

On one of the projects I am working on we are looking at setting up the red and green lava lamps as visual queues as to the status of the build. As part of the research in doing this we came across a great article on how to set the lava lamps up.

Some people may see this as a bit of a gimmick but I think it make the status of your build a focus point not only for the team but for anyone who comes into the project room. I have been on projects where the best intentions where to have continuous integration but slowly the build started to break and it became harder to fix and the quality of the build slowly deteriorated. If the team can have some pride in the status of the build and strive to keep that green lava lamp bubbling then I think it is a good thing.

You can’t refactor a design change.

Refactoring seems to be one of those concepts that has been bastardised as is become more mainstream. Turning to Martin Fowler’s Refactoring site, refactoring is defined as:

Refactoring is a disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior.

I just finished listening to Refactoring Part 2 from Software Engineering Radio. In this episode they talk about large refactorings, which in my mind seems to imply that you are changing the external behaviour. For a refactoring to become large (ie days or weeks) you really must be changing the behaviour in some way.

Refactoring is a technology process where we identify a smell in the code that either is or will shortly cause the code to become complex and we restructure it to prevent the complexity. In technology we sell this as a low impact process, we now have refactoring tools built into or IDE and we have unit tests to ensure we don’t introduce bugs. If your project gets to the point where anyone other than developers are suggesting refatorings to the code base then I question if what is being asked for is a design change.

External people see this and like to extrapolate that if technology can change the application and there is no impact to the schedule, they can too. I have been in the situation where management has suggested that we refactor in a change, meaning that the change will be quick and won’t impact the schedule. This is a design change it is not a refactoring. If there is a functional change to the application then you are not refactoring your code you are redesigning it. I think is is important that technology protect the concept of refactoring, it is a valuable discipline that allow developers to build quality into what they write.

If we allow the disipline of refactoring to be bastardised we will get to the point where refactoring is seen as the reason projects are ever budget and late not the fact that there was changing requirements and therefore a changing design.

Benefits and Risks of Introducing Agile to a Project

Sitting down and trying to present a balanced view of Agile methodology over a Waterfall or Iterative Waterfall methodology isn’t an easy thing. Agile addresses some of the core problems of waterfall based approaches that are down-played by those who practice waterfall:

1. Product Owners are asked to describe in detail exactly what you want the system to do when the project finishes.
2. What the requirements  of a project become and how much it actually costs really isn’t know until the end of the project.

In Agile a Product Owner only has to commit to the detail of a subset of stories, that make up a project, at the start of each sprint. During the sprint the development team is able to seek clarification from the Product Owner. At the end of the sprint the Product Owner gets to see what they have described as a complete set of functionality. Based on what the Product Owner sees they can then be feed into what they would like completed in the next sprint. This feedback loop between the development team and the Product Owner is a key to the success of agile.

Agile isn’t a guarantee of success so the following details some of the reasons you would adopt an agile methodology, but also some things that need to be managed to ensure that it is a success:

Benefits

• There is a constant two-way feedback loop between the development team and the Product Owner.
• The Product Owner is empowered to adjust the product backlog to incrementally tune what is developed.
• A completed story is production quality and can be defined to include automated unit and system tests, documentation etc
• It is easier to track what is complete, what is on the product backlog and how quickly we are developing (velocity)

Risks

• Requires appropriate business involvement in the prioritisation and elaboration of stories
• A team requires enough seed people with the necessary skills to start the project
• When multiple teams are involved there needs to be a concerted effort on coordinating the teams
• Because agile isn’t prescriptive it is hard to know if it is being executed correctly (Pro: feedback is at the end of each sprint)

Scrum Glossary

How to Predict the Future

Having a passing interest in investing, I always have a chuckle to my self when the subject of economists putting out forecast for some economic indicator is discussed. There seems to be one of two approaches that economists take to ensure that their credibility stays in tact:

1. Forecast that far in the future that people will forget what you said by the time we get there.
2. Forecast frequently so that you can tune your forecast.

 When I look at higher order architectures like enterprise architecture we are in effect trying to achieve that same as our economist friend and predict the future. Architects seem to adopt approach one(1) and create designs that are that abstract i.e. in the future that by the time the design is realised it could be a complete failure but still conform to the initial design. As great as this is for the architect in question, what benefit has it actually delivered for the enterprise.

The agile community at the coding level has adopted the approach that as we learn more we will adjust the application. Why can’t architecture take the same approach? To achieve this there are a couple of obvious things that need to be addressed to enable the process to be agile.

1. As the business evolves these changes in direction need to be communicated to the architect for refactoring them into the design. This is probably the one factor that can make or break being able to actually deliver a design that meets the requirements i.e. success or failure.
2. When you refactor code, unit test tell you if you have an interface or implementation dependency that has been broken, we need to be able to unit test our design when we refactor it.
3. Being able to architect in an agile manner requires a process that is light weight and is itself agile. Unfortunately a word document has no teeth so creating a process that is self validating at the architect level may be a little way off.
4. Following on from agility you also need to break down the problem into manageable chunk and solve them one at a time. Roger Sessions dives into this in his White Paper on A Better Path to Enterprise Architectures.

By applying the Manifest for Aggile Software Development to Architecture in general we can at least change the culture of trying to predict the Future. We can then focus more on trying to bring the practices  and tools up to a level where they can support the new process.