Test

Test post

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