Peopleware:Productive Projects and Teams: Book Review

The Book


Peopleware:Productive Projects and Teams by Tom DeMarco and Timothy Lister.


The Review

Like any other Software Engineering bible, the book is present everywhere: as reference in a large number of technical books, as reference in various articles, mentioned by fellow programmers and project managers, with fragments quoted in blogs and read in group readings, everywhere!

'Teamicide' did it! For me, it was the drop that filled the glass: another term from the quoted book that well describe acts I see around me. Next week I had the book in my hands.

The book came at the right time: after being part of a large variety of teams, after the PMI Project Management course, after the CMMI training, after seeing the "Scrum" steps my corporation takes towards Agile adoption.

What did I want to learn?

More about growing super productive teams and teamicide: what glues the team, what can destroy it?

More about project management, DeMarco & Lister's views on software engineering and project management.


What did I learn?

Learn is not a good word here, realize - works better.

1. Realized why I disliked sets of measures that I saw put in place in the environments I was part of. Defensive management measure set: mistrust, the Big M. Methodology, Laetrile.

2. Without any study in process control theory, DeMarco and Lister reach the same set of conclusions as Schwaber and Beedle: the management of indeterministic processes through Big M. Methodologies is doomed to fail. Excellent examples and comparations in this book: work-to-rule australian strike analogies, etc.

3. Realized why my former manager seemed to me so lucky. Having a strong team knowing what to do, with good moral and good accomplishments, feeling superior to the neighboring "regular" teams, the best of the best, was not an accident. His "Open Kimono" management approach, together with his active involvement in recruitment and contract negotiation phases - simply gave the right results: a super-productive team!
The general perception though was that he did nothing, all the good things just came on - sad but true!

4. Coding Wars: their scope and success criterias. I want to organize a session in my current company : if a fishing contest can be organized by my company, why not a coding one!. Tested the waters around here and it seems that a lot of people are interested in the topic - maybe after hollidays (Octomber) - we will run the first coding marathon in Eastern Europe!

5. Hawthorn Effect: give your team small potatoes to play with, challange them, celebrate with them, life is prety boring otherwise. Did I also mention that their productivity will reach the sky?! No, I'm not creating another Laetrile - there are good chances that the productivity will raise a little, but the important aspect is that the fun is guaranteed.

6. We are not working on High Tech Projects, we are not working on High Tech Projects, we are not working High Tech at all: all our problems are sociological in nature! Will I remember this?!
Will you realize this?!


In Summary

Sometimes you are allowed to take decisions that will affect your working environment: hire, buy a training, adjust office space, choose between technologies, set personal objectives, ...

It's good to have this book read at that moment. You might not be aware of your mistakes at that time!

If you are annoyed by a set of measures you see in your envronment and you don't know why, try to find the explanation here! You might find here a Plain English explanation and at least you'll know why you are upset!

If you think that nothing can be done in your case or your organization, that death is comming, use this book as a shoulder to cry on or as an ally to change the world!

Hmmm, the good Summary - after re-reading the book. The first read was just drink from firehose!

My "Dream" Team's Agile Profile

It took me 10 minutes to fill in a ThoughtWorks Agile Assessment questionnaire.

The filling was performed not for my current team, but for my "Dream" Team: the team I would like to be part of!

The results came shortly with ThoughtWorks quality level, we're almost at the top!



It's amazing how simple and small the agile vocabulary is : it can be covered in 10 minutes! The mentality shift instead ...

A Pattern Story

As mentioned in the previous post, the pattern story:

Being an adept of automated functional testing, knowing the complexity of our untested GUI classes, I knew we had to do something about it until it's too late. [The Right Time].

Knowing other attempts and their failures to introduce automated functional tests in my team [Test the waters], I did some Google research and quickly discovered FEST.

It's simplicity and it's java syntax attracted me, I knew it my have a chance of adoption in my current group [The Right Time]. I also was clearly aware about the benefits that automated GUI tests will provide us [Evangelist]

I started using them on my PC [Test the Waters, Just Do It] and spread the news to my friend co-workers [Innovator, Early Adopter].

We had discussions about the idea and the small progresses I had during lunch time: the time when people can talk! [Brown Bag]. Invited them to check for themselves [Trial Run].

After first successes [Small Successes], I began to spread the news on each occasion I had: invited fellow programmers to see the tests running and to assess their value, corridor discussions about status, etc [Stay In Touch].

I had the opportunity to discuss also with my boss about the possible opportunity [Guru on Your Side, Whisper in General's ear]

Our team had a dedicated day for developers only: Lock-down session.[The Right Time ]. In that specific day I proposed to have a look as a team to the FEST framework and the tests that can be done with it.

Decided that developers that have some experience with FEST to present it's features to developers who hadn't played with the tool: [Involve Everyone, Hometown Story, Trial Run] Simple demo's, no handy features! [Just Enough]

The concept was approved! We could commit our tests on SVN!

Started to build upon FEST a mini-framework better suited to our project's needs[Small Steps], let everyone know what I was doing [Involve Everyone]. Asked for help for SVN source organization and for the mini-framework design. [Ask For Help].

Ran the FEST test suite before each delivery of my module(the test suite was growing), invited everyone to see how I "do nothing" to test the release, and let everyone understand the amount of confidence a good suite of functional(GUI Tests) can provide[Smell Of Success, Personal Touch].

Similar test suites began to raise for other modules in my team and for other modules in neighbor teams [Early Majority]. Traditional skeptics became FEST fans and began to heavily contribute to the "GUI testing" phenomena. [Bridge-Builder].

The idea had more success than I expected: we have a colleague that became FEST Contributor, a colleague wanted to use FEST as an aid in his school presentations, started to use TDD, etc.

What I would like to do now is to thank again everyone who invested time and patience in this idea. Without their help, nothing would have been done: Thanks a lot guys, you really helped! FEST is now yours! ;)[Just Say Thanks].

Q.E.D

PS: If I only new earlier what I have learned from the book... :)

Fearless Change: Book Review

The Book


Fearless Change by Mary Lynn Manns and Linda Rising.


The Review

Heard about the new book quite a long time ago (December last year) when I saw the excellent InfoQ interview Linda Rising on "Fearless Change" Patterns.

Eventually the book became the best birthday present I have received in years! Thanks ;)

What did I want to learn?

I was intrigued by the handful of patterns for introducing New Ideas that were presented in the interview and I wanted to find out more. More patterns and more about each pattern.

I knew from the first minutes of the interview that the book presents solid, good quality material in an area of interest to me: Improvement.

I also recognized a number of patterns I have applied without knowing that they do exist (They are only Patterns, theee!). I wanted to find out what I already know from Linda and Marry Lynn's pattern language.

What did I learn?

1. A set of words.

When I finished the book, the pattern names were the first thing I remembered. Words describing situations in which I have been before, and unexplored situations I might encounter.

I know that what I will carry with me from now on will be the words (names of the patterns).

Like with any other pattern language I'm sure I'll remember it's words on hard, stressful situations. I'm already creating sentences, and I hope in the near future, I'll be better understood by others.

2. More about people, their expectations , reasons, powers and reactions.

More about Innovators, Connectors, Early Majority, Gurus and Generals and about the important roles they may play when a new Idea is tried to be introduced.

3. More about change.

A very important aspect that changed my perspective about my current job role expectations: you don't have to be named manager in order to lead! It's true, I lead teams form the shadow for as long as I remember, hoping that a job role will provide greater authority it's partly a false expectation! (Changes cannot be dictated)

4. More about what I've done.

Maybe like you, I have applied a lot of patterns in a variety of contexts. As described in the book, the patterns are not new, they might be seen as common sense, the only problem is that the common sense is "so uncommon" nowadays!

Anyway, there is a difference between applying unconsciously and applying consciously: I feel now details I wasn't aware of, I explain a lot of reactions, I'm more confident in what I'm doing, ..

5. More about what I haven't done. I have the feeling that I could have done more if I were aware of patterns like Guru on your side, Whisper in the General’s Ear, Personal Space, Token, Sustained Momentum, .... I see now how the list get's growing!


In Summary

For me, the book is a foundation stone in a domain doomed to always be on actuality. It's a result of many years of work and ... it really helps!

The book itself it's a new Idea in which I strongly believe. An Ideea I'm already introducing in my working environment: my colleague is reading it right now, and a third one is on the waiting list!

In a future post I hope I will be able to demo the pattern language in a nice Hometown Story, meet you there!

Second-class Citizens

I hear a lot recently that Test Code should not be treated as Second-class Citizen, that it is important, that is more important than the production code itself since it grows our confidence that we can re-work any piece of functionality without disastrous result in validation, etc.

Everybody seems now to know about the topic, although not everybody, not always tries to put the idea into practice: refactor test suites, use patterns when building them, create them when appropriate, make them robust, easy to extend, make them most suited for testing the current application, etc.

In my working experience I see a lot of other, not commonly known, hidden, Second-class Citizens.

I see: huge build files , production code labeled as "GUI" or "View" or "DB" part that is left to slowly rotten, javascript files, css files, xsl files, xml files, html files, resource files, etc. I can tell you for sure that all this buddies have one thing in common: toghether will affect every quality aspect appliable to your product!

Grow the monsters and you'll find yourself in big trouble. Sometimes you'll say: no, we can't do that, the "delete" feature breaks all our architecture, sometimes you'll just notice that every screen in your app looks different, sometimes you'll notice that any fix you perform, generates 3 more bugs!

Agile Software Development with Scrum: Book Review

The Book


Agile Software Development with Scrum by Ken Schwaber and Mike Beedle.


The Review

As part of the efforts to keep our projects on the right track, our teams are trying to apply Scrum. As a result, this book was bought by my manager as an alternative to a Scrum training that could not be taken in Timisoara.

After some research of his own on various books on the Scrum topic, he decided that this book practically is the foundation of Scrum and the first book that must be read on the topic.

It was a very wise decision. I'm also against 2-3 days trainings with no-name topic experts: they can only provide an initial image, for an in depth study of a topic, books and lots of research are needed. After reading it, I must say the book is a perfect starting point on Scrum methodology.

What did I want to learn?

• A confirmation that my view on the Scrum methodology formed from various blogs & articles that I read was right. (I have a lot of experience in XP, RUP, CMMI, PMI - I know a lot about agile and I read a lot of material stating that XP - Scrum - Lean are very much overlapping.)
• How various Scrum practices must be adopted? What do they mean?
• How can Scrum be adopted in our very large and chaotic project?
• Are there any more practices than Sprint Meetings, Daily Meetings, Backlog Burn-down charts and Sprint Retrospectives?

What did I learn?

• Compared to XP, Scrum seems to be more focused on management, control and various forms of organization - If Extreme Programming Explained lists a lot of Engineering practices, this book focuses on process and project management practices.
  
• Understood what is expected in Scrum from the various roles and why.(Scrum Master - removes impediments, takes decisions "any decision is better than no decision", mentor)
• Liked a lot "the art of possible" idea: What can be done in the current (poor) circumstances to reach the sprint's goal. It's not only Scrum master's responsibility to remove impediments, but creativity and adaptability is encouraged to all scrum team members - they must be aware that by themselves can remove impediments.
• Backlogs and Sprints - learned and understood why when adopting Scrum, Scrum practices need to be adopted by the book. Backlog - should be visible to every stakeholder and should contain all identified pieces of work (not only pure programming tasks). Sprints - very important to have a defined goal. Sprints - shelter against the chaotic needs from an application.
• Understood the scientific justification of Scrum practices and learned a lot about defined and empirical processes.
  
• Understood how large(multiple team) projects can be managed efficiently in Scrum.
  
• Scrum values
  

In Summary

The first step of Scrum adoption in any form of organization should be the reading of this book.
The book helped me gain deep understanding on this software development approach as opposed to various blogs & articles I have read which only presented me semantic diffusion.

SmellyRoom

As a software developer I fight "Smells" as much as I can.

I love the term, it's very plastic, intuitive and easily adopted by most of the people. I use it with different meanings: design smells (code that screams for refactoring), software aging smells (deprecated, dead code), testability smells (untestable code, low code coverages), etc..

I first encountered the term in Refactoring - Improving the Design of Existing Code, and I adopted it instantly. When I use the word, I'm understood immediately!

One of these days, I had a discussion with a colleague of mine and we laughed together about a new meaning of the word, or if you wish a new metaphor, old software projects as Smelly Rooms:

As you stay longer in a smelly room, you adapt, you find the air there more breathable. You even start to think there's nothing smelly with the air you bread. Same can happen when living too long in a Smelly Project, you can get used to the design smells, software aging smells, etc. It's possible you'll even start to think you're working on a state of the art piece of software!

The cure for this disease in both cases, smelly rooms and smelly projects: the door. Use the door to see the hallway, to enter other rooms, you'll just know you need to open some windows. Enter doors towards external projects (read books and articles, discover tools, have a look on an open source project, attach sources to external libraries you use and explore them, etc), and you'll just know you need to perform some cleanup to your old project.

Group Reading Writing

During the past year I had the opportunity to experience Group Reading, to continually grow understanding on this agile practice and to contribute to practice’s adoption and refinement in a number of development teams.

Reaching the time of year that is most suited for personal retrospectives (or was, I started this post on December last year!), it is time for me to write down a number of ideas, teachings and best practices discovered by trying to set up and get most of value from this learning technique.

What is it?

Group Reading is an agile learning technique that can be applied by a group of participants by simultaneously reading the same piece of technical text and sharing the individual understandings obtained from that text. The participants should be work related, i.e. parts of a development team or development group and the text should be interesting enough for each team member.

What can I gain from it?

If they are set up correctly and if they are continually subject for improvement, the group reading sessions may provide many benefits for each individual participant and for the team as a whole.

Each person when reading a text has his/her own paths of interest, words that are more appealing, paragraphs that worth more concentration, different reading and learning techniques used voluntary or involuntary (SQ3R, literary reading), performs analogies with past experiences, etc. As a result, when many persons share their understandings obtained from the same text, each person may learn from the others. It is very likely that missed points for one person to be very interesting ideas for another. So, each participant may read more in group than by reading the same text alone.

Other individual benefit for each participant would be the effective learning of the read topics. By discussing ideas and associating them with concrete examples, by putting them into context) ideas may become well sedimented in memory.(Learning by teaching and more).

Appetite for self improvement can also be a result of this practice (Why wait such a long time to finish this reading in group? I can buy and finish the whole book in one or two weeks and I’ll also read more in group reading sessions!). By reading small chunks reading appetite can be awakened, the book used in the group reading may be a start, but other books may follow also.

For the whole group the main benefit of this activity is related to group’s cohesion: common vocabulary and interests for the team members, common goals regarding future development work, growing respect between team members are only some of the aspects.

Good teams are formed over time, partly because team members have individual educational backgrounds and vocabularies, partly because teams need social background and good interactions.

Group reading sessions may help shorten the time needed to create good teams: by constantly adding common words in a team’s vocabulary, shared ideas as new words, the team may gain good communication skills and common concerns; by taking the team members out from their regular work environment, they may forget their working roles and socialize, feel equal, discover that some questions may be answered by someone near, respect each other’s ideas, etc. Yes, group reading is also a form of team building!

Finally but not at the last group reading session may be a small artifact in building a good working environment, where people put passion on what their doing, where auto improvement is constantly demanded.

What is it not?

Group Reading is not following a presentation, is not a discussion on known topic is not watching a technical podcast in a group. Is a simple reading act followed by a discussion and nothing more than that. Keeping it’s sessions simple, finding good subjects, can lead to the benefits listed above. Less is more, twisting and tailoring practice’s scope may not lead to optimal results for the participants.

Group Reading vs. Peer Programming

Peer programming is another agile practice that can lead to rapid teaching and learning and may help forming good teams quicker. My guess is that in many agile teams peer programming is the only training practice in use in the development phase.

This is normal until a certain point. The most appropriate teaching material intended to improve our work as programmers is the code itself, it’s abstractions, external libraries, documentation, design, etc. Having an experienced team member nearby is the best place to look for experience and good practices. During peer programming sessions, knowledge and skills owned by experienced team members may be rapidly shared with the whole team. The only problem here is the degree of knowledge and experience of the experienced team members: maybe different, better knowledge artifacts are recorded in an existing famous book or article or other form of documentation.

So if Martin or Kent or Robert or "you name it" is not yet your peer, maybe his/her recorded ideas could be your partners in group reading sessions!

Organizing Group Reading Sessions

As with any agile practice, the key in organizing effective group reading session is practice adaptation to real context: Just see if it’s appropriate for the team you’re in, try it, see what can be done to get the most value from it!

Over time, for groups I was part of, we discovered a number of points that lead to better group reading results.

In terms of duration we discovered that 30 minutes sessions are enough. 30 minutes sliced in 15 minutes reading, 15 minutes open discussions seemed the optimal amount of time we could stay concentrated on a new topic. We also discovered that almost any reading material can be sliced in cohesive parts that can be read in 15 minutes: 2-3 pages parts.

In terms of planning we discovered that is better to plan a number of subject related group reading sessions. This way the sessions became parts of a larger goal. A goal that can be tracked and addressed iterativelly (see progress monitoring, bellow :) ). Planning also implies priority. By planning 1 session per week we ensured that the whole group recognizes the session as being high priority. We obtained this way a group acknowledged priority.

In terms of participants we discovered that most of the group reading benefits can be obtained in teams of 3-4 persons. Having more than 5 persons in a group reading session tends to increase the open discussion time: every person tries to say it’s view on the read topic, etc. We also discovered that the degree of experience of the participants doesn’t matter too much: experienced developers can learn from beginners, beginners from beginners, etc. In one team I worked for we even played a lottery game to extract group reading session’s participants!

In terms of progress monitoring we discovered that having the planned group readings and their dates on a flip chart, a marker and the possibility to mark them as done, is good for the morale!