Posts Tagged People
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
Getting things done
Posted by Morten in Uncategorized on September 6, 2009
I just started reading “Getting things done” – by David Allen. I’m roughly 25 pages in, but now I have to stop to write this blog-post just to clear my mind.
The reason for why I started reading the book is that I found Tracks though mor.ph and started looking at their system earlier this week. The goal was to get some inspiration for creating more productivity enhancing features in RemoteX Applications. Tracks was interesting enough but I wanted to read the book to get some better insight into the ideas behind it.
The way Scrum, Kan-ban works is similar in the sense that it is a way to organize Actions, things need to be done.
What I miss so far from Getting Things Done is that the items on the team boards that I’m working on is also a part of the things I need to get done. It feels as if I’m missing a dimension. I felt the same way about the Tracks software earlier this week.
The book it self has already resulted in 5 blog posts, this included. Ill add one when I’m finished to summarize.
Computer anxiety
Posted by Morten in Uncategorized on August 26, 2009
I just talked to a neighbour of mine over the phone. She had a computer crash this morning, and basically panicked. Now as I talk to her I notice one thing that I’ve noticed over and over again. Most non-technical people are actually afraid of computers.
Now she knows the best practices. Regular backups, anti-virus regularly updated, anti-phishing filters activated. Still she refuses to download anything on the laptop, even Spotify was a hard sell apparently. Out of one thing, she doesn’t want anything to happen to the computer.
How do I ease the anxiety she feels when she is using her computer?
The amount of stress a computer can cause on a non-technical person is horrifying, and is something we should keep in mind when designing software.
A good user interface is a user interface your mother can use, without stress.
note: the person in the blog post is not my mother, but could very well be.SFUI = Stress free User Interface!
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.
Knowing the problem domain of a project
Posted by Morten in Uncategorized on March 6, 2009
When working with long running software projects. The initial stakeholders and developers often leaves before the project is complete, if it ever becomes completed.
As a result, the inital decisions made when starting the project can be forgotten. The experiences that lead to the project being initiated in the first place no longer exists in the team working on the project.
In some cases it can be good to have rotation of the people working with a project, but in in other cases it can be problematic.
Each software product has a problem domain related to it. If the developers on the project change too fast the knowledge of the problem domain can being to wash-out amongst the project members. The more washed out the knowledge becomes the more likely it becomes, that the development effort reiterates mistakes already done in the past. The worst case scenario ending in project failure.
It is important to stress that the reasons why a project is started in the first place should be communicated to new team members. If the problem domain and the reasons for the project is to known by the developers, chances of developing successful software are greatly reduced.
Working with a domain model
Posted by Morten in Uncategorized on March 4, 2009
We just took a new turn on the work with our Domain Model in RemoteX Applications.
In recent months, mostly due to the increased number of customers using the system. There had been some innovative ways in using the product. Some for which we hadnt intended the product to be used. Also requests were coming in that were requesting information to be ordered in a way that wasn’t possible using the existing domain model.
This combined with new team-members putting a slight strain in the communication, since the ubiquitous language was evolving based on new experiences and people. And the Domain Model wasn’t evolving with it.
As a result we had a meeting today, where we discussed the Domain Model, as is. The goal was to introduce it, and the reasons for it, to the new people on the team. But also to find a way to keep it more in line with the rest of the organization and our customers.
We came up with a few actions. One of them is to find a file based wiki to keep the documenation of the domain model in. That way, we can have the domain model checked in under source control, and update it as we update the product. The goal here is to not let the domain model get out of sync with the application, causing it to either become out-dated or as in our previous case risking it coming down with a bad case of YAGNI.
This change also makes it more apparent that the Wiki is for the developers to maintain, ensuring that the ubiquitous language alive in the development team.
Anecdote: People and Projects
Posted by Morten in Uncategorized on January 19, 2009
For som reason I had a flashback last night to when I was studying for my Masters. We had a course in project management based on RUP where the lecturer were hierd in from a consultant company specialising in RUP.
During one of the exercises I had a chance to have a discussion with the lead lecturer. The conversation was about the differences between RUP and XP (this was when XP was starting to get hot, the year after the course used XP instead of RUP). The lecturer said one thing during the conversation, and this one thing came back to me last night.
“As far as I can tell. XP bases it self a lot on having highly skilled and passionated people. Hardly any project can fail when everyone is highly competent and passionated about the project.”
The quote might loose a bit in the translation. This post is not about XP nor RUP. But the remembrance of the statement; its not how you do it but whom you do it with.