Your PM Partner's Blog

The Braintrust Consulting Group is pleased to announce Lonnie Weaver-Johnson, CSP, as its new Agile Practice Lead. Beginning in September 2011, Weaver-Johnson will manage Braintrust Consulting Group’s Agile Practice, and work with Braintrust Consulting Group’s coaches, trainers, and president to realize the company’s vision, mission, purpose, and goals.

Birmingham, Alabama (PRWEB) September 14, 2011 – With a background in coaching, training, and management, Weaver-Johnson has spent much of her career leading teams and individuals through Agile transformations. She has been a speaker at local events such as the Agile Experience Group and the Project Management Institute Minnesota Chapter Agile Local Interest Group and at global events such as the Scrum Alliance Scrum Gatherings in Chicago and Seattle. Weaver-Johnson has also been a trainer in her local community and has served as vice president of an area Toastmasters club. Weaver-Johnson’s ability to develop others will allow her to grow our agile practice and help our customer’s meet their goals.

“Lonnie is one of the strongest Agile coaches in our industry today. With over five years experience, she brings a wealth of knowledge and expertise to our team. Lonnie has coached offshore teams for years, a talent that will no doubt benefit many of our clients in today’s global economy. I look forward to working with her to grow and shape our Agile practice in the future, “said Brian Rabon, president of The Braintrust Consulting Group.

“I’m excited to be joining The Braintrust Consulting Group and Brian Rabon’s team of talented professionals. I also look forward to partnering with our customers so that they can use the benefits of Agile to reach their organizations’ goals. I am eager to support The Braintrust Consulting Group’s mission of sharing our love of Agile with others and am excited about the opportunity to grow the Agile practice so that others can truly benefit from this highly productive way of working,” said Weaver-Johnson.

For additional information on the news that is the subject of this release, contact Brian Rabon.

About The Braintrust Consulting Group:

The Braintrust Consulting Group provides complete project management solutions for a wide range of software-related projects. Our vast experience combined with our innovative project management model allows us to create customized solutions for each client. We blend People, Processes, Tools, and Training into one seamless formula to help our clients break through obstacles, improve processes, meet deadlines, and exceed goals.

Contact:

Brian Rabon, President
The Braintrust Consulting Group
205-329-3794
brian.rabon@your-pm-partner.com

http://www.your-pm-partner.com

###

To prevent a project from getting overwhelming, project managers break down their tasks into specified intervals called “sprints”. (Alistair Cockburn recommends one month, others will say these sprints can be as short as two weeks). You reach these “mini-goals” one at a time, and ultimately you reach the final destination.(Read more about the definition of these terms here, thanks to Method 123 for that information) Alistair Cockburn that we mentioned will be talked about in a later article on the blog so be sure to check that out for information on his perspective.

Organizing these sprints so that the time is most effectively spent results in a lot more than simply completing tasks. If done correctly, you can also analyze the team’s processes, customize the work being done, and re-structure where needed to ensure maximum effectiveness.

For this reason, PMs need what’s called a retrospective to happen every sprint. Every time you have the opportunity to look back at how things have gone, you discover an opportunity to improve the future. If there are some budget discrepancies, time management problems, or even just a few places that need to be tweaked but not really repaired, the retrospective is a great time to perform the routine maintenance that keeps your team running smoothly.

What a retrospective will look like:

Purpose:

The purpose of a retrospective is to establish what works, what doesn’t, and make changes to improve for the next sprint.

People who come:

Scrum Master, Scrum Team, optionally the Product Owner

Questions to Answer:

What works? What does not work? How do we want to improve?

Outcome:

List of action steps outlining how to improve, these steps get added to the Project Backlog.

You should allow for about 2 hour to complete the retrospective, but that 2 hours could save you countless more hours in repairs or problems that you are able to head off in one planning meeting.

Here is a great resource website that outlines a Scrum Retrospective meeting that you can print and use for your company.

When you are a leader, you have to be in control. Remember that control does not mean micro-management, but it also does not mean sit back and let it handle itself. Your team needs to have the parameters defined for them as to where they can work, how they can work, what resources are available, and what’s not allowed. Once you define these parameters, give your team the freedom to accomplish their tasks within the container, but be ready to be the source of answers when they have questions.

For example, one of your team members comes to you and asks about outsourcing part of his project to save on the budget. That might sound like a great plan monetarily, but what if the client has made specific requests prohibiting outsourcing? What if outsourcing negatively impacts the company reputation? There might by many–or no–reasons to either approve or disapprove this idea, but you as the leader have to be the determining point. You have to function as the tie-breaker.

Recently, a large investment banking firm was handed down an order from it’s parent company requiring them to achieve CMMI Maturity Level 3 (details on what CMMI means here). For those of you who are new to PM, CMMI is a very structured approach to project management, and relies heavily on strict documentation of processes. It works most often with the Waterfall type development lifecycle. For this particular investment banking firm, however, they were already employing Agile processes for software development when their parent company handed down this CMMI maturity level requirement. As a result, the bank had some big changes that needed to be made. Like many banks, this company did not want to change their processes because like anyone else, when something is working, why change? So rather than alter their entire approach, this banking firm turned to the CollabNet Application Lifecycle Management (ALM) platform to integrate Agile processes with the CMMI standards. In the article, the IT Director of the bank is quoted as saying, “CollabNet tools enabled us to develop a standard agile process template that met all the requirements of CMMI,…Plus, it provided the benefits of Agile without the need to be face-to-face, which helps our international teams collaborate more efficiently.” Read the entire story here.

This is the final installment of the guest blog submissions Jonathan Rabon has been writing for us. He is talking about the new process development he and Brian Rabon have been working on the past month.

This past weekend I attended a 2-day Certified Scrum Master (CSM) course in Tulsa, Oklahoma, led by Brian M. Rabon, CST, PMP. I thoroughly enjoyed the learning experience, was challenged by the material, and I gained new insights into Scrum and Agile practices. Giving up a weekend and traveling was emotionally and physically draining; however, the experience was more than worth it. I met course participants from as far away as Colorado and Texas from a variety of software companies and also one from a University. As a group, we grew together in our understanding and practice of Scrum process, and my desire to integrate psychological methods and Scrum practices was strengthened.

Here are some of the insights that I gained through the experience, along with some foreshadowing of what I plan to do with them:

(1) High bandwidth communication (i.e., face-to-face interactions) always trumps low bandwidth (emails, phone calls) for effectiveness. There is an astounding amount of information that is communicated in face-to-face interactions that is lost in more impersonal attempts at communication. I am trained in many ways to maximize communication, and I look forward to sharing my learning.

(2) Visual and physical based methods of organization (using sticky notes, white boards, etc.) are far more effective for encouraging self-management and self-organization in Scrum development teams than a long series of emails, phone calls, or leaving notes. So much time is saved when the status of each team member is placed together on a Scrum board or on any other organizing board. This eliminates the need for other people inside or outside of the team wondering who is working on what, and what stage of completion each task is at currently. I plan on using similar methods for communicating personality styles of each development team member in my methods.

(3) “Ask the team!” This is my new Scrum mantra. When in doubt, ask the team to determine what they want to do and how they want to solve a problem. This encourages ownership, motivation, and creative problem-solving instead of passive-aggressiveness and inefficiency. People don’t want to be oppressed by the decision making of micro-managers. Teams function so much better when each team member feels empowered by the ability to choose. Choice leads to a sense of ownership of projects and a more rewarding job. I plan to use personality testing results to empower development team members to have greater insight into the way they think, feel, and behave and to grow in whatever areas they deem appropriate.

(4) Teams comprised of people of different perspectives with different ways of thinking and perceiving, bring much greater levels of creative problem-solving than teams of similar ways of thinking. Also, when teams push themselves much farther than they previously considered possible they are far more likely to meet those seemingly unrealistic goals than teams that set the bar much lower. Growth can indeed be exponential when creativity is high and the team members are motivated. I plan to explore the personality style diversity on teams and have them integrate those findings into their daily work. By understanding the personality style diversity on their teams, developers will be challenged to reach new levels of problem-solving and creativity.

Well, now it’s time to get some rest and get back to the day job. Stay tuned for my next posting, coming soon.

Jonathan Rabon is guest posting for us this week and next week about the continuing progress of the process development he and Brian Rabon (President, Braintrust Consulting Group) are working on to integrate psychology into Scrum. Read on:

It’s early in the morning here in Colorado as I adjust to working a full-time job with a long commute and balance in time for writing and research. Nevertheless, this project is exciting and I’m driven to see it come to pass. Do you ever find yourself wishing that your Scrum team came with an instruction book? Well…that’s sort of what I’m working on.

I was reading a book by Doug Wilde, an Engineering Professor at Stanford University, entitled “Teamology: The Construction and Organization of Effective Teams.” Mr. Wilde came up with a method for using the Myers-Briggs Type Indicator, the same personality measure I’m proposing to use, but he uses it in a very “off label” sort of way. He shortened the test to 20 items and gave it to engineering design students to guide his setting up of creative, problem-solving teams. He uses his own mathematical formulas to justify his methods, but no one can argue with the results. Over 16 years of his implementation of this team-building strategy, his student design teams’ competitive awards essentially tripled.

I recognize that the professional world offers a whole array of different challenges than in the academic world. So I started planning my strategy. In the corporate world, teams are assembled based on fit for the job classification, sometimes on demographics (gender, race, ethnicity, etc.), level of experience, and for a myriad of other reasons. Although it would be wonderful to be able to create the “super team” from scratch, I know that in the real world that is usual rather impractical. Instead, I propose that it is far more useful to be able to understand the team you have and improve it.

I believe that the Myers-Briggs Type Indicator (MBTI) is the best tool for the job, but it needs some help. As you will see in my research proposal, there is plenty of research to back it up, but it needs an innovative method of application to truly help a Scrum team to flourish. I’ll tell you more about the MBTI and my method another time. Thanks for your interest and I look forward to continued progress.

The following article has been submitted by Jonathan Rabon, who is working with Braintrust Consulting Group to develop an entirely new process that strengthens the Scrum approach with psychology. Here’s part 1 of 3 of what he as to say:

I’m truly excited as I write this. It’s time to start writing my proposal. The research has been collected, the idea is coming to fruition, and now it’s time to explore a new niche where Scrum and Psychology can collaborate in a powerful way. Let me back up and tell you how I got to this point.

It all started on the evening of 6/26/2011 when having dinner with my wife and my brother at a restaurant in Colorado Springs, Colorado. Brian M. Rabon (Scrum Certified Trainer, a.k.a. my older brother) invited me to come to day one of his Certified ScrumMaster (CSM) courses in Broomfield, Colorado. I arrived not knowing what to expect. Once I was introduced to the class with my Doctorate in Clinical Psychology I thought the attendees would be intimidated or confused as to what I was doing there. It was not what I expected, they asked me questions and they thought it was totally natural for someone with a background in human behavior to be attending a specialized, project management training. I helped out in the training and I learned a whole lot.

I took detailed notes during the training and I remember writing, “Psychological testing for teambuilding.” With all the emphasis on small teams at the CSM training I thought that the teams need to understand the way that each other process information and their style of communication. The Scrum framework does a great job of minimizing the problems associated with operating in a team environment and all the biases that people bring to groups. It falls short in the understanding of the individual and what that individual brings to the team dynamic. That’s where psychology comes in.

I pitched this idea to Brian on 7/17/2011 and he thought it would be wise to propose a paper for submission to the Scrum Alliance conference in London. I scrambled to gather research; searching databases for psychology, business, engineering, consulting, and education. I found bits and pieces that supported what I wanted to do, but there was no prescribed method out there for applying personality testing to Scrum teams. In the void of research, Brian and I saw an opportunity.

I called on 8/2/2011 to let him know that the research has been collected, I made a crazily long outline of all my talking points, and he read it. We spoke again that night and discussed the importance of taking the science of personality theory and communication and applying it in a real world way with Scrum teams. He reminded me that I wasn’t writing an academic paper (although my former professors would have been proud), but instead I was writing a business proposal filled with selling points and ways to “achieve the vision.”

Even though I was anxious as I started to put my ideas to words, I began justifying and planning the method. Here it is in a nutshell…according to the Agile Manifesto, “We value individuals and interactions over processes and tools”; therefore, we need to understand how individuals think and how they communicate so that teams can work better. Using research-proven personality tests to find out the way that people process information and how they interact with other people can help us understand each other better. This is so important in a Scrum team of 7 +/- 2 (5 to 9) people on average. Small teams need great communication skills. Now you know the idea, but it’s time for me to get to writing. I will keep you posted.

We talked about the Global Scrum Gathering in Seattle on the blog, but for those of you who were not able to make it, you missed out on Lyssa Adkins!! So to make your life a little better today, we are sharing here an interview she did with Whitewater Projects. The interview talks about Agile coaches being organizational Transformation Agents. Whether or not you’re heavy into PM, you will like this video. Lyssa Adkins is one of the shining starts of the agile community, so we think you’ll like hearing her thoughts.

Watch the original film, as well as read some of the thoughts from the interivew on Whitewater Project’s webpage, here. Find out more about Lyssa Adkins here

When Alistair Cockburn decided to get his CST license, he did so with a broader goal in mind. With his involvement in Agile he was watching Scrum develop along side a great deal of confusion about just what Srum was, how to use it, and when. It seemed like a shame for such a promising methodology to go to waste over something as easily rectified as confusion over implementation. He felt compelled to help define the methodology of Scrum and give some concrete foundation to this new approach. However, to be a legitimate contributor to the process Alistair felt he must hold the proper credentials and thus he garnered his CST license in 2008.

Alistair then went on to pour himself into his training courses. He was offering Agile training courses, and even adopting the CSM certification when his client based started demanding that outcome from their coursework. A significant difference that set Alistair’s courses apart from his colleagues, was the genuine care he put into his work. Due to the fundamental shift in thinking and approach to project management that agile often brings, Alistair was concerned that two days was simply too short of a time period to allow new-comers to really “adjust to the different mindset of agile” (Alistair Cockburn’s article). So instead, Alistair offered (And still offers) a 3-day course, for the price of only two. While plugging away as contentedly as ever, he was approached in 2010 with the idea to create an International Consortium on Agile where a learning roadmap might be established to concretely layout the process of agile itself. Already a proponent of his infamous “hill top” analogy for describing Scrum, Alistair was hooked.

He started work on the soon to be formed “ICAgile” which would include “a 3-stage learning roadmap for each specialty (business analysis, project management, coaching & facilitation, software design and programming, testing, UX, and so on” (again, quoting from Alistair’s own words there). This creation was a great idea for Alistair, and one that would greatly benefit the project management community. Everyone on board was thrilled. There was only one problem: this new ICAgile was a competitor of the CST approach to agile, and contractually that constitutes a conflict of interest for a CST.

Therefore, in order to move forward into his new venture without harming the reputation of CST, Alistair graciously gave up his license as a CST to both preserve the integrity of the ScrumAlliance, and support their brand, by backing out of his contract as a CST and instead moving forward into the new venture of ICAgile. In his rather open and candid article on the subject, Alistair shares his belief that CST is a great option for project managers, and that indeed many options helps PMs diversify the field, and engage in certifications that meet their needs on personal and professional levels unique to each person. However, just as any creator would, Alistair felt his ICAgile was worthy of his exclusive time and he did not want to be simultaneously promoting other certifications that he personally felt did not match up with ICAgile. So while concludes by wishing the best to anyone who chooses to go with alternate certifications, he himself has made a personal choice to pour his efforts into ICAgile. So as 2011 is winding down, and 2012 on the horizon we wish Alistair the best and are excited to see where this new path leads him and the grand adventures we may expect from him in the future.

To read more about Alistair’s story, check out his article he wrote on the subject here.

You can find out more about ICAgile and the ICAgile certification here.

Have you ever seen an old war film where POWs are trapped inside a concentration camp and one lone leader emerges to usher everyone in the hut onto a team and ultimately to escape? After the obligatory battles and moments of tension, of course. Why is it that the POWs are not loyal to the Commander of the concentration camp? I mean, that leader is undoubtedly the control master of the camp. How come everyone abandons his mission in favor of the POW Leader and escapism?

The answer is obvious. People, as a rule, respond better to believing they are being served by the leadership rather than being dictated in tyranny. When we try to apply these principles to Project Management, however, a lot of team members begin to get nervous. Suddenly the obvious becomes significantly more vague.

The difference are not vague, and that’s a certainty. So let’s take a minute and debunk some of the myths surrounding servant leadership:

The needs of your client and the needs of your team members are not mutually exclusive and as a leader you have to be conscious of these things. Many battle leaders have led willing soldiers into horrible situations, simply because there was a tremendous amount of trust, loyalty, and respect for the leader among the members of the team. As a project manager, you build this trust and loyalty by placing the needs of your team on your priority list.

House the project goals in terms of what benefits the goals are bringing to the team. What’s in it for them to do a good job? Obviously, there are a certain amount of work ethic involved what says they should be there and do their best because it is their job to participate on this team. While that statement is undoubtedly true, as  leader you’ll do well not to exploit that reality.

You will not lose control of your team if you allow your members breathing room when it comes to executing different aspects of the project. When you have delegated a particular job to a particular member, do not micromanage them. Define the parameters within which they are to work, then let them decide how best to complete their task within those parameters. You will be surprised at how well your team members are able to perform in this environment.
Freedom of movement for your team will foster a personal investment in the project on the part of your team members. If you team members see the project as a potential success for them personally, they are more likely to perform at their best and deliver a quality project for your client.

So when you are leading a team, remember that remaining in control does not have to mean divide and conquer. Work with your team and operate with give and take rather than flog and punish.