Posts Tagged Teams
Getting things done with teams
Posted by Morten in Uncategorized on September 9, 2009
With this concept of quickly creating new tasks and with the GTD and How I work with code ideas. An idea for a new tool popped up in my head.
The tasks that I create based on working code, are cluttered with my own opinions. With the Getting Things Done approach we could have an inbox with Action times created as team members work with the code. In a Weekly review each item in the Inbox could be manage, prioritized, discussed. Some items result in items on a sprint backlog, others simply result in other team members explaining parts of the system to each other.
This weekly review could be conducted outside the normal delivery cycles, as they are partially meta tasks for achieving a common mindset of how and what should be developed. The result could be new features, refactoring, extra testing, reduced bugs etc.
The user always knows what he or she wants
Posted by Morten in Uncategorized on September 9, 2009
He or she might even know how to say it. It doesn’t mean that a developer will understand.
http://www.giantitp.com/comics/oots0676.html
Communication is everything.
How I work with code
Posted by Morten in Uncategorized on September 8, 2009
In Getting Things Done, David Allen discusses a work flow of how to handle things you need to-do. Now when I work at a coding task I often find places that could need some refactoring love, or needs to change in some way. There might be potential bugs, violations of DRY and all that.
What I’ve seen so far is that some developers tend to fix these “issues” as they find them, working towards a sort of zero-deficiency or a “if I cant read the code, chances are someone else wont be able to either” motivation.
Working with code in this manner can have some interesting side-effects. To name a few.
- It takes longer to resolve a specific task
- It could result in team conflicts a some developers perceive written code as “theirs”
- It could introduce bugs, if the original intent of the code isn’t captured by tests (not even 100% code coverage will guarantee this).
What I like to do is to finish the task I’m holding as fast as possible. The reason for this is simple; others are relying on it. But while I finish the task I notice these things that needs to be changed, fixed, or clarified. Code items that require attention in someway. What I tend to do instead is to create a new Task to represent this change.
Creating a new task as several benefits.
- It allows delegation and parallel execution of code changes
- It allows the task to be discussed by the team
- It allows me as a developer to finish my current task, without having to fill up my brain with new things to-do
- It allows me to finish the task faster
- It allows the new tasks to be prioritised by the team
- It reduces the chances I need to context switch
- It allows me to work on just one task
Now or the last one I recommend reading Eric Brechners blog post about making your world easier
The importance of teaching
Posted by Morten in Uncategorized on July 1, 2009
I have a good friend whom after university focused on first communication and then management. But now he has turned to development. We’ve been having a few discussion over the past few days about SOLID and REST and Grails. IoC containers and what not.
He hasn’t seen these kinds of concepts in his development so far. But he finds the concepts interesting and he is eager to learn about it. Which has given me a unique opportunity to learn how to communicate these concepts.
Now I’ve been an assistant teacher at the university. But I found that some of the benefits of these concepts are hard to explain, simply because to me their very abstract and I usually don’t discuss them at this level. I’d also like to mention that my friend is great at asking the right questions.
So this is a shout out to Joel. Thanks for teaching me how to communicate these concepts and their benefits.
ComparativeValues
Posted by Morten in Uncategorized on June 10, 2009
I recently read Martin Fowlers Bliki entry ComparativeValues. Where he talks about the values listed in the Agile Manifesto. Now Ive given this some thought and there are some things I find interesting.
If you look at it, what he says is that the Agile Manifesto it self is Agile. It was created as a statement to realign how we develop software, and move away from high ceremony project practices. In essence there could, and hopefully it will, where we need too define another manifesto to counter some other harmful development practice. To clarify, I mean hopefully as it would prove that our methods are improving and were Agile enough to adapt to the change.
Another thought which struck me is that making a list of Comparative Values could also be used as self help. Or a means to align your behaviour to a given wish. Create a list of 10 comparative values that describe how you as a person should act or behave. That you can refer to when making though decisions or just reflecting over your day at work.
Or why not create a Comparative Values list just for your team to take care of in team personal issues. How should we behave, what do we as a team value. Have the team develop a list that all members can commit too. That exercise alone should help shed some understanding between team members and could potentially help the team by reducing conflicts.
Source control folder anti-pattern
Posted by Morten in Uncategorized on May 21, 2009
I ran into this issue at work today. Another team depends on my teams code to create customer specific solutions. Now they have an issue where they have to keep track of which versions are currently in use, and produce software for the different solutions. Now I have issues with keeping more than one version of working software in production. The administrative cost for this is enormous and it keeps the organization from scaling.
This is one of the problems that could arise from keeping more than one version of the same software in production. The team that creates customer adaptions have to keep references to the different versions of code.
This means that they might have to compile the same code but with two different versions of the software. Either they keep two versions of their software checked in under source-control at two different locations, or they keep two versions of the references checked in, or both.
Using source-control in this way defeats the purpose of using source-control. You do not use the time dimension of the source control system, instead your just using it as a shared folder.
Instead the way to use source-control is to check-in the references for each version they have to support, in order. Keeping them at the same place, this enables them to get the specific version of the reference and compile a custom delivery for that specific version. That way you are working with the time dimension instead of working in parallel to it. Dependency management can become a pain in the rear if you don’t use the tools for what they are worth.
Sprint startup
Posted by Morten in Uncategorized on May 18, 2009
A while back we started with one-week sprints. For several reasons. We had four-week sprints earlier, but sometimes it was unclear what we were supposed to deliver and what we delivered.
Today we started our third one-week sprint. The start-up meeting took 20 minutes, and was a stand up meeting. Everyone was standing up. In effect it was just a longer Daily Scrum, with more details of what we were going to do and how.
This week is a short week in Sweden, (holiday in the middle of the week, so most people take vacation days to get a long weekend). Thus the one week sprint is in reality 2 and a half day. During which we will be automating the deployment of some of the plug-ins for RemoteX Applications. We have now roughly used half the sprints avaliable hours, and were mostly done. Leaving tomorrow for fine-tuning and testing of the builds we created today.
Technical team-building
Posted by Morten in Uncategorized on January 15, 2009
I firmly believe that; if a team has a common view of how software is to be developed. The team can produce software a lot faster.
If not only for the fact that if the team shares a common view of how code is structured, in an object-oriented sense, then the communication cost between the team-members goes down. The individual team-member can figure out how the developer whom wrote a shared resource implemented specific features of that resource.
A common problem for this is that the team has different backgrounds and experiences. Which gives each individual developer a different opinion in how to develop software. Just take the example of the ever old Test-first or Test-last? Test-at-all?
Having technical team-building sessions could help close the gap between competences of different developers over a team.
Here are some ideas for holding technical team-building sessions
A technical team-building should be designed to give the developers of a team a common ground, or reference point, for how to design software.
You could have a mentor come in and have the developers go through exercises to learn specific techniques.
Give the team incentive for having all developers read a specific book. This book could then be used as a reference when having technical discussions. The goal being to establish a common set of principals for how to software is to be designed and developed. Communicate this goal frequently.
If you have a specific developer on the team who is into TDD and similar techniques, a suggestion would be not to have that developer introduce it. Instead have a mentor come in from the outside and demonstrate/teach the techniques. That way the developer becomes a natural source of knowledge for the team. Without risking that the team views the developer as know-it-all.