Too many streams spoil the broth?
I was chatting with Eben about the current state of affairs at work. We got around to talking about the personnel and projects that my place has on the go.
The development staff consist of seven developers (one of which is the MD, one of which is me, with the obvious coding time impact for both of us) and roughly three testers.
The projects on the go, split roughly by a combination of technology and client number seven major and two minor.
If I count the two minor projects as one, and the MD's and my available development time as one developer, that's 1.125 projects, per developer!
This level of task diversity for our developers had never occurred to me before, in my defence this was largely the status quo before I even joined (bar one project or so). I wasn't exactly going to join and be able to convince the upper management to give up revenue streams.
All this is a far cry from Eben's situation of one team, aimed at one collective software goal (or at least, that's my current take on their situation).
It's obvious we need more staff, and there is an ongoing recruitment process. In the meantime the demographics lead to some interesting thoughts around the right way to structure the teams.
I may as well get around to admitting one of the Agile sins: We have a great deal of "infrastructure code". While I understand this can often be a bad thing, in this case it does serve to unify a lot of the work done in one language - indeed three of the biggest projects share exactly the same shared code base, with client-specific code on top.
Therefore I could potentially unify teams by language. This would help unify developer interaction. It would spread domain knowledge. It would create more of a team environment as the biggest team would now comprise of five 1/2 developers, plus two testers (say). I think this could be a marked improvement for the team dynamic; giving them the chance to really interact.
However, it presents a difficult question from the other side of the Agile coin: Specifically with reference to the Product Owner. How could a unified team like this serve the needs of the respective Product Owner for each client? I think the joint most important part of Agile is that it ends up (if done correctly) creating software the client wants. How then can the Scrum Master (say) use such a unified team such that each Product Owner's priorities can be folded into one Product Backlog?
It's this challenge that has prevented me from unifying the team, so I'm paying the price in terms of the greater complexity my current set-up creates.
Posted in Coding, Agile | no comments |
Measured measuring
KPI's can destroy a teams morale and productivity if they are not carefully considered. Every organisation likes to measure the performance of their employees, some more formally than others. It's pretty easy to see what your metric is in a sales environment when deciding who is and who is not doing their best. Measure the value of their sales activity and you get a pretty good idea how well they are performing right?
In a development environment it can be tricky to know what to measure. There are plenty of potential performance metrics to choose from, everything is done on a computer so naturally you can track and measure it. The problem is one of choice. Whatever metrics you define as your criteria for success will become the focus for improvement. Hence the power of both measuring and rewarding salespeople on pure sales numbers.
For developers, measure lines of code (LOC) committed and they will duly write more LOC. LOC alone means nothing; it could be crappy code right? It's better to measure for the outcome you want. Find some way of measuring quality and that becomes the incentive. Measure it and the team will naturally seek to improve it.
In Scrum there is the team's sprint burndown, which shows how quickly they get through their story points and how likely they are to finish the sprint tasks. A longer trend you could measure is release planning, where you do a similar thing to a burndown but for the whole project/release.
This is all fine for estimating and project planning but in measuring quality it's not much help. Again, what you measure as 'quality' will depend on your situation but some possibilities include: unit test coverage, defect count, uptime, customer feedback, use statistics. Whatever it is you measure, make sure you can get the data reliably and at the right level of detail.
Posted in Coding, Agile, Scrum | no comments |
Some good practice for agile coding
While the process framework behind Scrum and Agile in general gets you thinking about how you organise the work and the facilitate the team, it's only half the story.
For software development teams there are some engineering practices that can help the team code well within the people and organisational processes that Agile implements. The aim of these engineering practices is to allow the development team to create the best software product possible. These are enabling approaches that allow us to focus on the most important aspect of software development; not engineering practices but building the right software.
The idea is to define and agree a basic way of working that allows us to focus on writing great software that satisfies the business. By using some good engineering practices we remove the waste in a developers day and allow them to get on with coding.
What follows is a mixture of engineering practice and working practices that I've had some success with.
Control your code - It's just good practice to use revision control however you decide to run the project. We like subversion.
TDD/BDD - Test Driven Development or Behaviour Driven Development. Write your tests first and then write your code to fulfil those tests. This way you don't end up with no time to test and it means you're doing the design up front in small chunks. People often wonder where the Architecture is in Agile, well if you do TDD the way it was meant to be done then when you write your tests you're actually designing how the code should behave. Effectively the TDD cycle of test-code-refactor is an inspect and adapt design process, that a developer goes through in cycles lasting minutes.
War room - Your team and their interactions are the single the most important factor in the success or failure of a project. If you can get all your team in one room and make it their war room it will help the team to be cohesive and develop a sense of shared values and team practices or behaviours.
Continuous Integration and Automated Testing - Automate both unit testing and acceptance or functional testing. Ad hoc testing is a bad idea - by automating the building and testing in the code control system you ensure that the software builds at every check-in; this is continuous integration. Developers will feel more comfortable changing existing code and refactoring, no one forgets to run the tests, you spot errors early, development becomes more flexible. For a test framework in Rails apps there is Rake, Zentest and Test::Unit for Ruby, and for JUnit for Java. For acceptance testing there is Selenium and Fitnesse. Cruise control for Ant enforces continuous integration in Java.
Quiet time - When you're in the zone and cranking out quality code like it was gong out of fashion, the last thing you need is an interruption. Once you've been rudely awakened it can take ages to get back into the right frame of mind for problem solving. Agree a quiet time with no phones and email or devise a physical signalling system like a busy flag so people know not to interrupt.
Automate those documents - Use software that extracts relevant information from the code and creates some of your documentation for you. That way your documents show you what is really happening with the software. It almost documents itself. So much more useful than some spec that says what should be happening.
You should also look at pair programming. Once I've had more experience of it I'll post my thoughts on it. Check Ron Jeffries site for more.
Remember, not every practice works for every situation, try them out and keep what fits. Make sure to get the team to agree their working practices - enforced ways of working that validate and measure the wrong practices and metrics wont deliver you software, let alone agility.
Posted in Coding, Agile, Scrum | no comments |
An Agile Overview
I'm going to give a brief overview of an Agile development process called SCRUM. At the end of this article are some links to further information for those of you that want to read about SCRUM in more depth.
First some terminology:
- Scrum Master - The person who enables the Scrum process, a facilitator
- Product Owner - The person ultimately responsible for defining the product and its features
- Iteration - A set cycle of development time
- Sprint - Scrum name for the iteration cycle
- Development team - Everyone it takes to get from requirement to tested releasable code (coders, testers, Q&A, Analysts, DBA's etc)
- Velocity - A measure of the completed features for a given iteration
The first thing you need to begin Scrum is a Product Backlog. This is essentially a list of features or in my case user stories. This initial list - just enough to get you started - should be prioritised by the Product Owner according to business priorities. Next you'll need to decide on your iteration lengths. Typically a team starts with iteration lengths of 30 days but some teams prefer 2 week iterations.
Now you're ready to begin Sprint planning. Sprint planning is usually split into 2 four hour section - during the initial phase of planning the Development Team sit with the Product Owner and the Scrum Master to estimate items on the Product Backlog. These should be sized according to their relative complexity - that is 'how big is this feature?' not 'how long will it take?' Points are awarded to each User Story. This meeting is usually time-boxed to around 4 hours with as many features as possible estimated in that time. Times for daily scrums and the end of Sprint Review and Sprint Retrospective are also agreed.
With the backlog estimated and prioritised the team work out how many of the most important items on the Product Backlog they think they can do in the allotted Iteration or Sprint period. This can be based on the teams current Velocity if the team have been sprinting together for a while or it can be based on the expert opinion of the team. Based on the items chosen from the Product Backlog a Sprint Goal is agreed with the Product Owner.
For the second half of Sprint Planning the team take the list of items to be worked on during the Sprint - the Sprint Backlog - and break down each item into more granular tasks covering everything from coding to meetings. These tasks are estimated in hours to complete. The team then commits to deliver the functionality in the Sprint Backlog along with the overall Sprint Goal.
Once the Sprint begins there are daily meetings of around 15 min where the team gets a chance to inspect and adapt again. Three key questions are asked: What have you done, what are you going to do and what has been an impediment to your work? It is then the Scrum Masters role to work with the business to remove those impediments to progress for the team.
Once the iteration comes to a close the larger inspect and adapt cycle kicks in. There is a Sprint Review with the product owner to go over all the code completed in that iteration. The Product Owner runs through the software to be sure it meets the original requirements and if it does the team are awarded the points for each user story deemed complete. These team points are their Velocity - a measure of the amount of functionality/complexity that they can deliver per iteration. This review period is also a chance for the team to share their work and get feedback from the rest of the company.
The best time for a Sprint Retrospective is right at the end of the iteration. During the retrospective the team looks at what went well and what didn't and looks to adapt accordingly. Once the retrospective has been held its back to Sprint Planning and the iteration cycle kicks in again.
Some further reading.
Books:
Agile Project Management with Scrum
Agile software Developement with Scrum
Websites:
Posted in Coding | no comments |