Knowledge, Understanding and Skill. The three stages of learning (according to Japanese TQM). I have found this to be true. In my opinion a little knowledge can be dangerous, understanding comes only with experience and skill is acquired only after repeated practice in varying conditions.
The theme of learning, has been central to my blogs on Agile development. One of the tenants of the agile manifesto is to value people over process. If you accept that software is a complex non-deterministic, creative discipline, then this primary tenant must be true.
As an organisation, if you value people over process, then it is only logical that you get good at developing people. As an individual you owe it to yourself to improve.
I have been using XP for sometime, and up to now I have reserved judgment on its general applicability. Well I feel that I've learnt enough to come off the fence and offer an opinion.
I don't think XP provides enough guidance on how to get the best out of people. How best to build and develop individuals and teams. XP says go get a skilled team, apply these practices and bingo success. But if the team is not skilled, or worst still, if they think they have the skills, but in reality do not, what then?
In a sense this is an opportunity for people like myself to offer our services as "Coach". Come in, exhibit skill and leave with a fat check. But what happens after we go?
I have been reading Crystal Clear (CC) by Alistair Cockburn. CC advertises itself as a human powered methodology. I prefer to think of it as a people centric approach. It was developed over several years by interviewing sucessful agile teams and asking what worked. The outcome of these interviews has been boiled down into a number of guidelines for success.
CC addresses many of the short comings of XP, by truly focusing on people. I have got my own ideas on how the two approaches could be merged, taking the best from each. I'll save that for another blog. I'll leave you with an omission in XP, that if you think about it is a startling oversight.
How do people improve? People learn from other people, often by example. For this to occur a relationship between teacher and pupil(s) must exist. This relationship is very important and requires mutual respect and personal safety. In the relationship the teacher leads, and the pupil follows. The essential skill of the teacher is leadership. Without good leadership improvement and eventual success is unattainable.
XP does not address the concept of leadership. Instead it assumes that a meritocracy will arise within teams and appropriate leaders will be found at appropriate times. My experience is that what is as likely to occur is that the blind will end up leading the blind. Alternatively, in scenarios where several people have the required leadership ability, uncertainty and confusion can arise as no one knows who to follow.
You only need to look to Sport to see that teams need leaders. Good leaders get the best out their teams.
Monday, May 30, 2005
Saturday, May 28, 2005
Agile Development - Understanding
Another entry on my role as agile coach. My last entry on this subject told what happened when I looked for management support to help solve an internal problem. It wasn't a surprise when the management support was not forth coming.
The problem was that some team members did not understand XPs approach to design, and as a consequence were adding technical debt to the project at a rate of knots. Worst still, they did not accept my authority.
What to do? Well in a last ditched attempt I called an impromptu brown-bag session on agile design, and the cost of change. I described the need to "flatten" the cost of change curve when performing agile development, and I used examples from the project to make the point. The session was discussion based, with members of the team asking questions and offering opinions. It became clear very quickly that the team members that were hostile to TDD just did not have an appreciation of the cost of change, never mind how best to address it.
During the meeting I could see knowledge transform into understanding. They had heard the terminology before, some had even skimmed "XP Explained", but this was the first time that they actually understood.
After the meeting, members of the team who had previously said that "they knew it already", asked to borrow my copy of "XP Explained". There is evidently a big gap between knowledge and understanding. Perhaps I should of held the brown bag earlier. Yet I have a feeling that without the pain that the team went through, the less experienced would not have understood. Knowledge and experience leads to understanding. Knowledge on its own is not sufficient.
Consequently my authority in the team has increased. The doubters, doubt a lot less, and are more willing to take my lead.
Thinking through the lessons learned, I've concluded that this episode demonstrates a weakness in XP. How do you ensure that the less experienced developers do not cause too much harm. Especially if they feel that "they know it already"? XP provides no guidance other than to avoid inexperienced developers. I've been reading Crystal Clear - which provides a pragmatic solution to this problem. Let them do non critical tasks, like bug fixes and maintenance.
This idea brings us back to where we started - managing people. As a leader I need to be recognised as such and empowered, but XP does not stress leadership.
In fact XP provides little guidance on people issues. In some ways I find XP a bit de-humanising, reducing software development to a set of rigid disciplines. In contrast, Crystal Clear takes a more people centric approach. I can see myself borrowing from Crystal Clear in the future.
The problem was that some team members did not understand XPs approach to design, and as a consequence were adding technical debt to the project at a rate of knots. Worst still, they did not accept my authority.
What to do? Well in a last ditched attempt I called an impromptu brown-bag session on agile design, and the cost of change. I described the need to "flatten" the cost of change curve when performing agile development, and I used examples from the project to make the point. The session was discussion based, with members of the team asking questions and offering opinions. It became clear very quickly that the team members that were hostile to TDD just did not have an appreciation of the cost of change, never mind how best to address it.
During the meeting I could see knowledge transform into understanding. They had heard the terminology before, some had even skimmed "XP Explained", but this was the first time that they actually understood.
After the meeting, members of the team who had previously said that "they knew it already", asked to borrow my copy of "XP Explained". There is evidently a big gap between knowledge and understanding. Perhaps I should of held the brown bag earlier. Yet I have a feeling that without the pain that the team went through, the less experienced would not have understood. Knowledge and experience leads to understanding. Knowledge on its own is not sufficient.
Consequently my authority in the team has increased. The doubters, doubt a lot less, and are more willing to take my lead.
Thinking through the lessons learned, I've concluded that this episode demonstrates a weakness in XP. How do you ensure that the less experienced developers do not cause too much harm. Especially if they feel that "they know it already"? XP provides no guidance other than to avoid inexperienced developers. I've been reading Crystal Clear - which provides a pragmatic solution to this problem. Let them do non critical tasks, like bug fixes and maintenance.
This idea brings us back to where we started - managing people. As a leader I need to be recognised as such and empowered, but XP does not stress leadership.
In fact XP provides little guidance on people issues. In some ways I find XP a bit de-humanising, reducing software development to a set of rigid disciplines. In contrast, Crystal Clear takes a more people centric approach. I can see myself borrowing from Crystal Clear in the future.
Sunday, May 15, 2005
Agile Development - Management
Back to bloging about my experiences as an agile coach. In my last entry I mentioned that we were weeks away from our first release, but that we were also burdened with technical debt.
Well, we have delivered our first release (sort of), but it has been painful. The more experienced developers in the team, are now quite aware of the impact of technical debt, mainly as a consequence of having to refactor large swath's of the system inorder to implement the final few stories.
The technical team lead approached me and asked what to do? Quite frankly I was stumped for an answer. The problem was that some team members were quite convinced that their "up front designs" were playing a vital role. And in their opinion their views where just a valid as mine. After all, common sense dictates that unit testing is about testing, not design right?
By this stage my attempts to persuade them otherwise had failed abysmally. Our team leaders' attempts to assert some influence had failed too. People are complex. The reasons for resisting TDD by some team members are still unclear to me. What was clear though, is that their stance was putting the project at risk, and that management should be informed.
So I penned an e-mail to our manager. It had to be an e-mail, since the only person I could clearly identify as taking direct management responsibility was based in the States (all the team members including myself and the customer assigned team lead are contractors). As a consequence a tele-conference between myself, the technical team lead, the onsite customer assigned team lead, and the offsite manager ensued (if this structure sounds complex, that is because it is!).
Nothing much came of this meeting other than me being told: "Call me back when there is a crisis" by our Manager. So what is the moral of the story? The pointy haired boss is alive and well, even on agile projects.
Well, we have delivered our first release (sort of), but it has been painful. The more experienced developers in the team, are now quite aware of the impact of technical debt, mainly as a consequence of having to refactor large swath's of the system inorder to implement the final few stories.
The technical team lead approached me and asked what to do? Quite frankly I was stumped for an answer. The problem was that some team members were quite convinced that their "up front designs" were playing a vital role. And in their opinion their views where just a valid as mine. After all, common sense dictates that unit testing is about testing, not design right?
By this stage my attempts to persuade them otherwise had failed abysmally. Our team leaders' attempts to assert some influence had failed too. People are complex. The reasons for resisting TDD by some team members are still unclear to me. What was clear though, is that their stance was putting the project at risk, and that management should be informed.
So I penned an e-mail to our manager. It had to be an e-mail, since the only person I could clearly identify as taking direct management responsibility was based in the States (all the team members including myself and the customer assigned team lead are contractors). As a consequence a tele-conference between myself, the technical team lead, the onsite customer assigned team lead, and the offsite manager ensued (if this structure sounds complex, that is because it is!).
Nothing much came of this meeting other than me being told: "Call me back when there is a crisis" by our Manager. So what is the moral of the story? The pointy haired boss is alive and well, even on agile projects.
Subscribe to:
Posts (Atom)