- You have to hire "ninjas."
- Programmers need to work in quiet, without interruption.
- Start-ups run hot, so we're just gonna have to burn everyone out.
- Looming deadlines necessitate shortcuts.
- Developers should take ownership of their code.
- You need a quirky hiring process.
- Specialization is essential.
Sunday, June 12, 2011
Debunking Some Start-up & Software Myths
I saw a great article by Tim Ferriss quoting Rob Mee of Pivotal Labs thanks to someone I follow on Twitter, and thought I should mention it here. It's rare that I read an article on a topic like this and agree with it 100%, but it happened in this case. I encourage you to check out the post itself, but in order to whet your appetite, here are the 7 Myths he describes:
Saturday, April 16, 2011
Agile 101: A Workshop
It's been ages since I posted anything here, but now seems like the perfect time to end that drought. Yesterday, I spent the morning and part of the afternoon at a large local company that wanted to get an introduction to Agile. Since one of the people involved with that initiative is a friend and former co-worker of mine, she put out the call to AgileMan and I was more than happy to answer it!
To accommodate the request, I designed a two-part session that lasted 4 hours. There were 22 attendees, along with two colleagues of mine (my wife, Vicki, and another friend). The first half was a presentation called "Agile 101: An Introduction to Agile", in which I did my best to describe what Agile is, and what it isn't. I started off with a very high level definition of Agile (from Wikipedia) in order to provide at least a notion of what it is, and then talked about why we decided to "go Agile" at the work place where I gained the AgileMan moniker.
Next, in order to put some more flesh on the initial definition of Agile, I took the approach of looking at Agile from several different perspectives, specifically trying to capture what people often assume Agile is when they first hear about it:
I then spent a consider amount of time going through some of the more common principles and practices in the Agile community, such as:
I had to go at a brisk pace through the presentation because we had a full-on activity to do after the break, and that unfortunately meant that I couldn't spend as long on some of the questions as I'd have liked. By this point in my career, it's gotten very easy to tell the difference between a back-and-forth that may eventually lead to a resolution and one where the other person has already made up his or her mind on the subject. I tried to keep the former type going while cutting the latter ones off, but I'm sure I did an imperfect job at that in the final analysis.
After a 15-minute break - during which time I was inundated with more questions, which is always a good sign - we began the hands-on portion of the workshop. The 22 attendees were split into 3 groups of about 7 people each, and each group got one of myself, Vicki or our other guest as their Product Owner. All 3 groups were tasked with "building" (on paper only) the Meal Planner application, based on a visionary set of requirements (lacking in specificity, by design). The deliverables for each feature included screen design/diagrams, test conditions and help texts, and the teams were given four 20-minute iterations in which to do as much of it as they could.
Interestingly, all 3 groups started off working in smaller groups - screen UI vs testing vs help - only to realize, by the end of the first iteration, that they hadn't known enough about what their teammates were doing to be able to do an effective job on their stuff! We had short planning sessions to start each iteration, followed by the doing, then a hand-waving "demo" to the Product Owner and a quick Retrospective before beginning the next iteration. This exercise worked extremely well, as it provided everyone with a taste of what Agile is like: short cycles, lots of adaptation, emerging requirements, high degree of collaboration, etc. As far as I could tell, everyone in the room was fully engaged in the activity, and there was a palpably-high level of energy present for those eighty minutes!
After the 4th iteration, each team briefly presented its "application" to the others, along with what they'd learned in their mini-Retros. Then we wrapped things up, at which time several attendees offered quick testimonials about what they'd learned and how much they'd enjoyed themselves, which was very gratifying to me and my two helpers.
As I usually do in workshops, I handed out a very short, 1-page survey to encourage the attendees to provide feedback on the session. I asked them to rate three things:
It still remains to be seen whether I'll be asked to do any more Agile consulting for this particular company, but the signs are promising at this point. Several topics were mentioned as potential areas they'd like help with, including estimation skills, breaking large features up to fit into short iterations, Retrospective facilitation and Product Owner-type training or consultation.
All in all, it was a great day and it took me back to my initial two years as AgileMan!
To accommodate the request, I designed a two-part session that lasted 4 hours. There were 22 attendees, along with two colleagues of mine (my wife, Vicki, and another friend). The first half was a presentation called "Agile 101: An Introduction to Agile", in which I did my best to describe what Agile is, and what it isn't. I started off with a very high level definition of Agile (from Wikipedia) in order to provide at least a notion of what it is, and then talked about why we decided to "go Agile" at the work place where I gained the AgileMan moniker.
Next, in order to put some more flesh on the initial definition of Agile, I took the approach of looking at Agile from several different perspectives, specifically trying to capture what people often assume Agile is when they first hear about it:
- a response to the historical high failure rate of software projects
- a loosely-knit collection of lightweight development approaches
- a way of doing iterative programming
- a mitigation strategy against ever-changing customer requirements
- a commitment to quality and customer satisfaction
- the latest buzzword, fad or silver bullet
I then spent a consider amount of time going through some of the more common principles and practices in the Agile community, such as:
- Inspect & Adapt
- Empower Teams
- Size Relatively
- Co-locate teams
- Work at a sustainable pace
- Don't compromise quality
- Automate your testing
I had to go at a brisk pace through the presentation because we had a full-on activity to do after the break, and that unfortunately meant that I couldn't spend as long on some of the questions as I'd have liked. By this point in my career, it's gotten very easy to tell the difference between a back-and-forth that may eventually lead to a resolution and one where the other person has already made up his or her mind on the subject. I tried to keep the former type going while cutting the latter ones off, but I'm sure I did an imperfect job at that in the final analysis.
After a 15-minute break - during which time I was inundated with more questions, which is always a good sign - we began the hands-on portion of the workshop. The 22 attendees were split into 3 groups of about 7 people each, and each group got one of myself, Vicki or our other guest as their Product Owner. All 3 groups were tasked with "building" (on paper only) the Meal Planner application, based on a visionary set of requirements (lacking in specificity, by design). The deliverables for each feature included screen design/diagrams, test conditions and help texts, and the teams were given four 20-minute iterations in which to do as much of it as they could.
Interestingly, all 3 groups started off working in smaller groups - screen UI vs testing vs help - only to realize, by the end of the first iteration, that they hadn't known enough about what their teammates were doing to be able to do an effective job on their stuff! We had short planning sessions to start each iteration, followed by the doing, then a hand-waving "demo" to the Product Owner and a quick Retrospective before beginning the next iteration. This exercise worked extremely well, as it provided everyone with a taste of what Agile is like: short cycles, lots of adaptation, emerging requirements, high degree of collaboration, etc. As far as I could tell, everyone in the room was fully engaged in the activity, and there was a palpably-high level of energy present for those eighty minutes!
After the 4th iteration, each team briefly presented its "application" to the others, along with what they'd learned in their mini-Retros. Then we wrapped things up, at which time several attendees offered quick testimonials about what they'd learned and how much they'd enjoyed themselves, which was very gratifying to me and my two helpers.
As I usually do in workshops, I handed out a very short, 1-page survey to encourage the attendees to provide feedback on the session. I asked them to rate three things:
- how effective the presentation portion was at introducing them to Agile
- how effective the hands-on activity was at introducing them to Agile
- how effective the Product Owner had been in helping them understand Agile
It still remains to be seen whether I'll be asked to do any more Agile consulting for this particular company, but the signs are promising at this point. Several topics were mentioned as potential areas they'd like help with, including estimation skills, breaking large features up to fit into short iterations, Retrospective facilitation and Product Owner-type training or consultation.
All in all, it was a great day and it took me back to my initial two years as AgileMan!
Subscribe to:
Posts (Atom)
