Another post I made to the Agile-Testing Group recently:

Here's a simple estimation excercise. My honest advice is don't just read it; actually try it. It takes about two minutes.

To start, think about the space between the bottom of your feet and your knees. Write it down. Then think about the space between your knees and your middle. Write that down.

Then estimate the and write down the size of your torso, then your neck, then your head.

Next, add up all five numbers.

Now compare that to how tall you /actually/ are.

That difference - between how you imagine things and how they actually are - is a picutre difference between task estimates and how long things will actually take.

Except of course, you can see and touch your body and it's been about the same height for decades, whereas code is new and fresh and symbolic and 'tests' are an even-more abstract concept.

When you think about it, tests are a first-order derivative of the code itself. Also, most testing is exploratory in nature, EG early predictions are not the best predictions.

So would I be reluctant to make task estimates on a testing task, given the typical American shorthand that estimate==commitment? Certainly.
I like to think of this as the test estimation rabbit hole. First, we have to have the bad news that test estimation is conceptually impossible.

Then we figure out how to do it anyway.

More to come.

Cincinnati, OH – September 2, 2010 – Seapine Software, Inc. today delivered new capabilities to testers with the general availability of QA Wizard Pro 2010.2, its leading automated functional testing application. QA Wizard Pro 2010.2 now includes web application load testing, which enabl ...

In Agile, everyone agrees on the concept that continuous improvement is a good thing. In Scrum and also in most Kanban practices we even have a ceremony to support this, namely The Retrospective. This periodically occurring meeting (often every other week) with the entire team plays a vital part in the process and in team [...]

One of the most common anti-patterns I've seen in waterfall projects is the "90% done syndrome". It goes like this: the project will get quite quickly to 90% readiness and will look to be on time until that point. However, after the 90% readiness point is achieved we start to see more and more delays and blast through deadlines like there was no tomorrow.

Why is that? I've spent some time thinking about this question. With Agile projects we avoid this syndrome quite effectively by managing the scope. In practice we avoid the "90% syndrome" by declining to work on the content that would delay the project but not add enough value to justify that delay. But, then some time ago the question came back to me. Why is it that in waterfall projects we have the "90% syndrome"?

The answer to that question just hit me today (a real "d'oh" moment): the reason is that we don't really know about all of the requirements until we are well into the implementation (say 70-90% into it). Therefore we will only really understand the full content of the project when we are close to the end. This, coupled with the fact that waterfall projects tend to be organized architecturally/horizontally (instead of feature/vertical sliced) leads to knowing about critical requirements too late(90% ready for a long time) and not being able to remove content (because we release the lower layers before the upper layers) to meet the schedule.

This anti-pattern is quite simple, but apparently it takes time to understand the forces at play, and most managers (including project managers) constantly miss this point...

Photo credit: striatic @ flickr

By Maria Matarelli

I’ve used Scrum on many software development and IT projects.  In addition to the projects I was working on, I received a request to work on a role-advisory team tasked with analyzing the effectiveness of a specialized project role.  This new team was pulled together with minimal allocations and replaced a full-time team that had just been disassembled due to budget cuts.  Given the constraints and uniqueness of the project, we decided to use Scrum for our approach.  It worked—flawlessly.

Demanding Circumstances

The going was uphill from the start.  We were a team of ten, allocated to contribute only 20 hours per person over the entire calendar year.  The team was just told, “Go.”  Success was undefined and the scope was unclear.  With a meager budget and minimal direction, we had to guide role development, training, knowledge sharing, and create a solution to provide overall direction to support more than 150 people.  The only thing we knew for certain was that the requirements were bound to change as work progressed.

As we discussed our options, it became more and more apparent Scrum was the right approach.  The limited ingredients and project constraints were the perfect recipe for a self-directed team.  Though we could have easily made the business case for additional funding, we were told from the beginning that “additional funding is not possible.”  Any solutions we found would have to be found within the team itself.  Frequent, incremental deliveries would help bring clarity to the project vision.  Though only few of us had used Scrum outside of IT (and most of the team had never used Scrum at all) we felt it was the perfect solution for the constraints facing our team, constraints that probably sound familiar to many teams out there. 

A Creative Solution

I was elected as the ScrumMaster.  My job was to guide the team through the framework, facilitate our meetings, keep the team focused on the goal, and remove any impediments standing in our way.  We selected the functional manager as the product owner, our primary interface with the other stakeholders.  We created a product backlog, using the list of work items as epics and categorizing the stories appropriately.  We ranked the priority and voted on the complexity of the stories.  With the limited availability of our team, we could only work on very small chunks of work within a sprint.

Our success with Scrum was directly tied to the team’s commitment and buy-in to the framework from the beginning.  Those that were new to Scrum listened to the overview of the artifacts, roles, and ceremonies, and eagerly applied the practices to the work to be accomplished.  As a result, project overhead was reduced and the team began producing results immediately.  In the coming sprints, the team was able to collaborate more effectively, giving them the time they needed to maintain their existing workloads.

Something to Prove

Meanwhile, the people who were working in the role that we were redefining had little confidence in the announcement of a new guidance team.  Although they had been promised changes by previous "strategy teams" the end results were not always seen or had little value.  Our team was able to build trust with this community by sharing our backlog and deliverables in a collaborative online environment.  This transparency enabled our team to provide a forum for iterative and incremental feedback.

Our team went further into engaging the input of these and other stakeholders.  It was apparent that we neeeded to gain buy-in in a short amount of time.  I introduced the team to Open Space, a meeting format in which a theme replaces the traditional agenda and the participants identify the topics for discussion.  Using Open Space, we asked the people what they wanted to talk about and enabled them to self-organize and discuss the topics that were important to them.  The greatest benefit from our use of Open Space was the involvement from the people that attended.  Our team was then able to get input on many items in the product backlog from the entire community while also gaining their buy-in and understanding the root of any issues.  While many of the backlog items were completed within the Open Space session, we also added new stories as a result of the discussions, helping us to avoid critical oversights.  By engaging the community in such an open way, we not only were able to greatly increase our velocity in a given sprint, but also were able to uncover additional ways we could enhance the role and truly deliver value as a team.

Space to Work

The product owner asked me to explain our approach and review the backlog with other stakeholders, including high-level managers.  The backlog prioritization received a lot of scrutiny.  The stakeholders had many questions as to why certain items were chosen for the current sprint over others they felt were higher priority.  Their questions gave me an opportunity to explain the Scrum framework.  I discussed planning and complexity size. I talked about how we worked with the product owner to deterimine our priority and took into account work for future sprints through release planning.  I explained the need to bring in only one or two high complexity stories per sprint and how we broke large stories into smaller deliverables.  Given our team's velocity, some lower-complexity stories were often brought in to help round out the sprint with what we could accomplish to achieve some quick wins.

After explaining the rationale behind backlog prioritization and sprint selection, management and the other stakeholders trusted the team’s approach and allowed us to continue working without interruption.  The Scrum framework worked as designed, protecting the team, the work in progress, and ultimately the project’s overall integrity.

A Clear View Changes Perspectives

Another benefit of our approach and backlog overview was that it gave management insight into how much work we could take on during a sprint’s timeframe and still fulfill our other work commitments.  Had the other managers been able to interject new work mid-sprint based on their own prioritization schedules, the team would not have been able to deliver and would have accumulated multiple work in progress activities without completing any of them.  By displaying the work priorities in the backlog and communicating the timing of the sprints, we were able to project which work items could begin in the next sprint without interrupting the current sprint.  The framework provided a means of having a single source for prioritization.  It is not always easy to tell a manager, "no," but when you can explain the framework you are using to complete the work and provide them a controlled mechanism to provide input to the work, they will have a way to navigate work priorities without disrupting the team.

Scrum Just Fit

This was a small team of people in a large corporate arena.  Our ability to adopt the framework and willingness to try something innovative is how this project got “done” in spite of the constraints that come with large enterprise.  The product owner quickly picked up on his role and was very engaged.  The team self-organized, took on the work we could, and consistently completed the work we set out to do.  Our managers understood what we were doing and left us alone to do it, meanwhile still having input into future tasks.  We gave our customers the ability to communicate their concerns and opinions through collaborative tools and open space activities, a key factor in our success. 

We pulled off the near impossible, moving from a challenge with countless limitations to a valuable end result.  We credit Scrum's simple framework for enabling our high productivity.  Through self-organization and collective incremental delivery, we built momentum that translated into real value.  Our experiment, born of necessity, was a true success and is a model that other projects can follow.  While we can’t change the whole business all at once, we can inspect, adapt, and start the transformation one opportunity at a time.

Please note: borisgloger.com became multilingual! The original feed now contains solely German content. To follow borisgloger.com in English please update your feed-subscription.

In einem meiner Professionell ScrumMaster-Training zum Thema Teamentwicklung kam, wie schon in vorherigen Seminaren, bei mehreren Teilnehmern die Frage auf, „wie können wir als ScrumMaster unsere Teams und Teammitglieder schneller (am besten sofort) dazu bringen, selbstorganisiert zu sein, mehr Engagement und Dynamik zu entwickeln, sich endlich zu bewegen“. Die (verständliche) Ungeduld der ScrumMaster war deutlich spürbar und zeigte auf, dass die am Scrum-Prozessen Beteiligten häufig in sehr unterschiedlichem Tempo vorangehen, um Scrum zu adaptieren und zu integrieren. Geht man dieser Frage etwas auf den Grund, stößt man unweigerlich auf das Thema Lernen. Scrum ist ein komplexes Verfahren und erfordert auf mehreren Ebenen Lernprozesse von allen Beteiligten. Diese komplexen Lern- und Übungsprozesse werden m.E. unterschätzt, oft zu wenig berücksichtigt. Ihnen wird zu wenig Zeit und Raum gegeben.

Die Lernebenen in Scrum-Kontexten beziehen sich auf

• Methodik und Technik des Verfahrens
• Scrum-Metaprinzipien,
• Scrum-spezifische  Arbeitsstrukturen,
• neue Rollenmuster,
• Arbeiten in Teamkonstellationen
• Veränderungsdynamiken in Systemen

Diese komplexen Ebenen erfordern also gleichzeitig fachlich-rationales, soziales und personales Lernen, in der Regel unter Zeit- und Erfolgsdruck und stellen somit echte Herausforderungen für alle Betroffenen, besonders aber für die Teammitglieder, dar.

Einige Thesen zum menschlichen Lernen

• Menschen lernen in unterschiedlichen Geschwindigkeiten
• Komplexes Lernen ist ein ganzheitlicher Prozess auf rationaler, emotionaler und körperlicher Ebene und realisiert sich bewusst und unbewusst
• Komplexes Lernen ist ein Erfahrungsgeschehen, das im Idealfall durch rationale Informationen und dem Erleben von konkreten Situationen neue neuronale Strukturen in verschiedenen Bereichen des Gehirns generiert und mit der Zeit ausbaut und stabilisiert. 
  Dies gilt für alle oben genannten Lernebenen.
• Lernen jeglicher Art heißt üben.

Komplexes Lernen verläuft in vier Phasen in einem nicht kontinuierlichen Prozess (d.h. mit partiellen Rückschritten, Stillständen, Bags):

1. Phase der unbewussten Inkompetenz
2. Phase der bewussten Inkompetenz
3. Phase der bewussten Kompetenz
4. Phase der unbewussten Kompetenz

Überträgt man diese Phasen auf Scrum Lernen ist die Phase 1 die “Phase der Unschuld“, in der die Betroffenen noch nicht wissen, dass sie bezogen auf Scrum nichts, oder nur sehr wenig, wissen.
Im ersten Kontakt mit der neuen Lernherausforderungen in Phase 2, in Einführungstrainings, dominiert in der Regel das Gefühl, die neuen Lernanforderung noch nicht wirklich zu beherrschen, d.h. bewusste Inkompetenz. Angesprochen ist hier vorwiegend rationales Lernen, begleitet von Unsicherheit, unbewusster und bewusster Abwehr, aber auch Neugier und echtem Interesse und Engagement.
Die dritte Phase der bewussten Kompetenz vollzieht sich in den Tagen und Wochen der Scrum-Einführung, der ersten Plannings und Sprints, Meetings, den Kontakten mit den externen Beratern usw. Hier entwickelt sich über Erfahrungslernen und Lernen vor allem im kollegialem Dialog, mit emotionalen und rationalen Anteilen, bewusste Kompetenz auf den oben beschriebenen Lernebenen. Allerdings verläuft Phase 3 nicht kontinuierlich sondern es kommt, je nach Erfahrungskontext und Lernmöglichkeiten immer wieder zu Rückschritten und Einbrüchen in Phase 2, mit all den Unsicherheiten, Frustrationen und Blockierungen die das Oszillieren zwischen bewusster Inkompetenz und unbewusster Kompetenz so gut wie immer begleiten. Diese Symptome werden von außen häufig als Unwillen, Phlegma, Unklarheit, Desorganisation, ja Widerstand wahrgenommen  (manchmal von ganzen Teams, manchmal von einzelnen Mitgliedern) und negativ bewertet.
Im Idealfall entsteht mit der Zeit (aber nicht ganz von selbst) immer mehr bewusste/unbewusste Kompetenz (Phase 4) und das Arbeiten mit der Scrum-Methodik und Strukturen, im Team, mit der Scrum-Rolle etc. wird voll beherrscht, automatisiert und durch meist unbewusste Routine-Muster sicher gesteuert.

In der Scrumpraxis sollte und muss also allen Beteiligten die notwendige Zeit für die komplexen Lernprozesse gegeben werden.

• Scrum als komplexer Lernprozess sollte von Anfang an gezielt thematisiert sein und differenzierte Lernphasen gezielt eingeplant werden.
• Besonders in Retrospektiven kann der ScrumMaster in seiner Funktion als “Trainer” Lernprozesse zu verschiedenen Themen anstoßen und trainieren (braucht m.E. für Retrospektiven mehr Zeit als meist gedacht).
• Bei konkret auftretenden Problemen und Konflikten in Plannings,  Sprints, Daily Scrums usw. können situativ Lernsituationen initiiert  und reflektiert werden.
• Gezielte Phasen der Lernreflexion (Scrum Lessions) können regelmäßig, strukturiert und über eine definierte Zeitspanne angeboten und durchgeführt werden
• Kollegiale Coachinggruppen für ScrumMaster und/oder Product Owner können kollegialen Lerneinheiten bieten.
• Externe Unterstützung durch Teamentwicklung, Coaching, Training kann genutzt werden.

Immer wieder fällt gerade im Zusammenhag mit Scrumeinführung auf, dass Lernen in unseren Unternehmen in der Praxis immer noch als “Sondersituation“, ja geradezu als “Luxus“, definiert wird. In der modernen Arbeitswelt mit ihren permanenten Veränderungsanforderungen müssen jedoch gesteuerte Lernprozesse zwingend als normaler Bestandteil der Arbeit, sozusagen als “Tagesgeschäft” gesehen werden, wo immer dies notwendig ist.

Arbeit ist Lernen und Lernen ist Arbeit ist die Devise.

Dieter Rösner
Head of Trainings

Related posts:

• Schuldzuweisungen verhindern Lernen
• Führung in Scrum | der Manager | Fähigkeiten | Teil 3
• Werkzeuge für ScrumMaster: Die Moderation

It is amazing, you can talk to someone, use words that make perfect sense to both parties and still, they don’t communicate at all. I had this experience last week. The Scrum Teams I have been coaching for some time now were scheduled for a meeting with a manager. It was about certain company standards in the area of reporting. The different Scrum Teams were doing the same thing in slightly different ways, no big differences but enough to be visible. Those differences had a good reason: Different preferences how each team wanted to work. Since the teams are self organizing, there is nothing wrong with this approach and either solution makes perfect sense in their given context.

However, in that meeting the POs and SMs of the two teams were told that having different reports was not acceptable – that they could be confusing; which they weren’t because we had already moved people around – and that the company would mandate a specific tool enabling anyone to work anywhere without having to get any introduction. This might work if all the teams would do the same kind of work, however, in this setting the different teams do a different kind of work using different technologies.

I knew that that specific meeting was scheduled to address that very topic. So, on purpose I did not mention this beforehand to neither of the SMs and POs. I was curious to see how they would react and how they would argue. I wanted to see if I was doing a good job as a coach. It was a textbook show. They simply said: ‘No way! We have delivered working software on time since we started with Scrum, this is how we agreed to work in our Scrum Team and it works great for us. We had people moved around and nobody was confused. Last, there are more pressing issues than how certain reports should look like!’. Of course, the manager was not pleased. He argued that this had to be done in order to align the whole company and lay a foundation for future improvements. The Scrum Teams replied by explaining some principles and practices of Scrum. They also described how it makes sense to keep on working the same way and that they would be open for some changes when both teams would see the need for it – however, right now they do not welcome it.

This went on for the best part of the hour. Sadly at the end we were told that we would have to obey with whatever decision the management would come up with. Our reasoning was not understood – we had failed.

What had happened? Each party was perfectly able to follow and understand each word of the discussion. However, the management side did not extract the same kind of information. We had a semantics disaccord. They understood each single word but did not get the meaning of what we were trying to communicate.

I’ve come to the conclusion that this could be explained with the Dreyfus model of skill acquisition.

• Expert
• Proficient
• Competent
• Advanced Beginner
• Novice

The Scrum Teams each had about 6 months of hands-on Scrum experience and discovered first hand what it really means to walk the agile walk. They learned a lot about agile and enhanced their theoretical knowledge with hands-on practical experience. Their limited explicit Scrum knowledge became tacit and abundant. Tacit knowledge is knowledge that is difficult to transfer to another person by means of writing it down or verbalising it. It was exactly this tacit knowledge that was missing on the managers’ side to really understand what we were trying to explain. Same words, total different meaning.

The Scrum Teams have moved up the Dreyfus model and are around the competent or even proficient level, whereas the management is still novice, advanced beginner at best. We had an interfacing problem and did not communicate on the same skill level. The risk with that is that you think you understand, but don't understand without realizing it.

I am convinced that this is one of the main challenges when communicating certain topics. You cannot assume that everyone has the same tacit knowledge and thereby the same skill level then you. You need to find a way to describe matters to a novice as tangible as possible. Not an easy feat but a necessity.

Consider the Dreyfus Model whenever you head to a meeting where you have to do a lot of explaining. If you are too far apart on the Dreyfus model, the others won’t be able to understand even if they think they do!!!

SAN FRANCISCO--(BUSINESS WIRE)--Embarcadero Technologies, a leading provider of multi-platform database tools and developer software, today announced the worldwide availability of Embarcadero® RAD Studio XE, a suite of development tools that includes new versions of Delphi®, C++Builder®, ...

• dzone.com - Google Offering Programming Courses for Free Including Android Developement Course
• Android - Google Code University - Google Code

An agile process replaces upfront design with the focus on the ability to react and to decide based on the current situation. But, to take the right decision we need to be able to assess the situation accurately and fast. However, software systems are large and complex and they handle large amounts of data. Thus, they present many more details than we can reliably control. Approaching the problem in an ad-hoc manner does not benefit us.

Assessment is a critical activity to ensure proper decisions involving large amounts of details. And it is expensive, too, with various studies reporting assessment to account for as much as 50% of the total development effort. As such, it should be addressed explicitly in the development process.

In this talk, Tudor Girba will provide an overview on the problem of assessment and illustrate how the current popular approaches fail to solve it because they are either ad-hoc or too generic. He then describes agile assessment, a new approach that puts emphasis on offering contextual and continuous feedback.

Speaker

Tudor Girba attained his PhD in 2005 from the University of Berne, Switzerland, and he now works as a consultant at Sw-eng. Software Engineering GmbH. His main expertise lies in the area of software engineering with focus on software assessment, and he is currently helping companies assess and manage large software systems and data sets. He is one of the main architects and developers of the Moose platform (http://moosetechnology.org), and he participated in the development of several other assessment tools, models and techniques. He is the president of the Moose Association and the Treasurer of the Swiss Group for Object-Oriented Systems and Environments (CHOOSE).

08:00  -  08:35  Registration, Coffee & Gipfeli 08:35  -  09:50  Talk & Discussion  09:50  -  10:50  Networking, Coffee & Informal Discussion
Free Coaching! Bring a problem or help with the solution! 3x 20 Minute Sessions in the coaching room.

Time, Location:

• Date: Wednesday, 6 October 2010
  
• Location: SwissICT, Vulkanstrasse 120, 8048 Zurich (above the Jeep-Dealership).
  
• Registration through the SwissICT
  
• The LAS core team will meet from 11.00 to 12.30. Interested people are more than welcome!
  

P.S. If you are not yet a member, please support the SwissICT and become a member! They provide the venue, coffee and gipfeli without charge so this can stay a free event.

patterns & practices Parallel Programming with Microsoft .NET is now available.  The book shows design patterns to help developers use the .NET 4 Task Parallel Library (TPL) to write parallel applications successfully.

Contents at a Glance

• Authors and Disclaimers
• Foreword
• Preface
• Acknowledgments
• Introduction
• Parallel Loops
• Parallel Tasks
• Parallel Aggregation
• Futures
• Dynamic Task Parallelism
• Pipelines
• Appendix A: Adapting Object-Oriented Patterns
• Appendix B: Debugging and Profiling Parallel Applications
• Appendix C: Technology Overview
• Glossary
• References

The Patterns
The book describes six key parallel patterns for data and task parallelism and how to implement them using the TPL.

The Book

• Free in HTML -  Parallel Programming with .NET (MSDN)
• Print / EBook -  Parallel Programming with .NET (O’Reilly)

The Code Samples

• Parallel Programming Code Samples (CodePlex)

The Talk

• Patterns of Parallel Programming (TechEd)

The Community

• Parallel Programming with .NET Community KB (CodePlex)

Here are the slides from my keynote at the Scrum Gathering in Cape Town.

• What to do when Scrum doesn't work - PDF
• What to do when Scrum doesn't work - Powerpoint

Positive atmosphere and lots of laughs, really enjoyed the audience! The whole topic felt a bit like poking a stick at a hornet's nest. Looks like I got away with it though, at least so far :o)

Slide samples:

Here are the slides from my deep-dive workshop at the Scrum Gathering, Cape Town:

• Kanban for Scrum practitioners, PDF format
• Kanban for Scrum practitioners, Powerpoint format

Thanks for attending! Lots of interesting questions and insights came up during the workshop.

Sample slide:

According to Dictionary.com, a community is:

1. a social group of any size whose members reside in a specific locality, share government, and often have a common cultural and historical heritage.

2. a locality inhabited by such a group.

3. a social, religious, occupational, or other group sharing common characteristics or interests and perceived or perceiving itself as distinct in some respect from the larger society within which it exists (usually prec. by the ): the business community; the community of scholars.

The 3rd definition applies to the Agile Community. From my point of view a community is really the network of relationships between the people who are its members. The more relationships we have and the stronger the individual bonds the stronger the overall community will be.

After Agile2010 I made a suggested over twitter that the Agile Community is Fragile and needs nurturing. Unsurprisingly I got a number of reactions and created some confusion which wasn’t my intent. My key point was that as the community continues to grow and create new conferences: LSSC, XP Universe revived[1], SCNA, XP 2010 (ok this one has been around for a while), we’re at risk of breaking into camps and cliques. Groups of people who spend their time inside one community and who don’t spend enough time listening to each other and the outside world. This trend has been going on for years after all who aside from Ron Jeffries and George Dinwiddie have the time and energy to spend on every mailing list [2].

Towards my goal of strengthening the community I suggest we all commit three actions this year:

1. Seek people from outside your regular circle i.e. if your non-technical meet some new technical people; Scrummies meet Kanbanners. Whoever you meet, pause, listen (don’t spout) and learn.
2. Strengthen bonds with people you already know, especially outside of your regular circle
3. When you introduce someone to Agile, introduce to more than the ideas and approaches you favor today. I.E. Kanban folk mention Scrum or XP; BDDer’s mention TDD – help new people discover the full spectrum of ideas.

As our community grows ever bigger lets remember that have much in common even when there are major differences.

Related Ideas: A Community of Thinkers (Jean Tabaka, Liz Keogh and Eric Willeke) and Oath of Non-Allegiance (Alistair Cockburn).

[1] As an aside I still think that Agile Technical Practices would be a better name for this one, emphasizing the practices are important whichever methodology you subscribe to.

[2] see: Agile Mailing Lists for an attempt at listing them all

Welcome to the roundup of blog posts and pages that mentioned Sonar last month…

5 Java powered open source tools for your team
By Alex Collins, 27 August 2010
If you’re a Java shop and want to ensure you can support your team’s toolset, here are some pointers for the must-have tools we modern developers use day-to-day.

Killer tool: Sonar
By Erwin Vervaet, 27 August 2010
Today a colleague at work showed Sonar to me, and I must say that I was really impressed! Sonar is an open source code quality analysis tool that uses a number of popular Java code analyzers like PMD, CheckStyle, FindBugs and Cobertura under the hood, …

Cross-referencing plugins in Sonar 2.2
By Josh Cummings, 19 August 2010
Formerly, we had three Sonar plugins, two “mavenly” dependent on the other. The parent plugin held the common code for uploading non-Java files into Sonar for reporting. The other two took care of analyzing xml and css, respectively, and tying violations to those files.

Integration Tests in Sonar
By Josh Cummings, 19 August 2010
Integration tests are another important aspect of analyzing a project’s overall health that Sonar does not yet support out of the box. To get this functionality, you’ll need to build a couple of Sonar plugins (or try using the ones that I built) that will instrument your integration test code, run the integration tests, and collect the integration test results as well as the new coverage data.

Architecture Analysis Tool SonarJ 6.0 Supports Structural Debt Index and Quality Model
By Srini Penchikala, 16 August 2010
The latest version of software architecture analysis and quality governance tool SonarJ supports structural debt index metrics and architecture quality model. The company behind the product, hello2morrow, last month announced the release of version 6.0 of the tool.

Maven 3 and Sonar
By Anders Hammar, 16 August 2010
Another step towards a final release of Maven 3.0 was made the other day when version 3.0-beta-2 was released. I’ve been using Maven 3 since its alpha days, and despite the alpha/beta moniker, I find it to be superior to any Maven 2.x version. If you are starting a new project, I strongly recommend using Maven 3.

Reporting more than Java code in Sonar (Part I)
By Josh Cummings, 3 August 2010
Of course, anyone that has done static analysis on their project in the past has found certain bad practices that are out of their tools reach to spot. Some examples are…

This is a news update, not another card, but our latest article is up at Pragmatic Programmers. 

We've gone a few weeks without a new card here, but it's because we've been working on the final versions of our cards to be published by Pragmatic Publishers "Real Soon Now."  You will find a lot of familiar content, but even more polished and even more condensed. You'll get to enjoy physical cards, suitable for sticking and sharing with your whole team or company.  Even better yet, they'll have been edited by actual professional editors.

We're not going to quit the blog, but we are going to be available in more forms than ever before. PragProg will release AgileInAFlash as physical cards and as ebooks.  Imagine how cool "Courage" or "ABCs of Pair Programming" will look on your hot little iPad or Android phone!   You'll have virtual Tim & Jeff everywhere you want to take us.  This blog continues to be a place to write your comments, or to see cards never before released into the wild.

When you get your deck(s), take a picture of yourself using the cards and send it to us. We'll be thrilled and honored to see how you use your AgileInAFlash in your daily work!

Blessings.
Tim

Evolving Excellence is hosting this 108th edition of the Management Improvement Carnival.  Previous carnivals can be found here.  Of we go with a sampling of posts from the past couple weeks.

• Gemba Panta Rei: 5 Ways the Obeya Increases Profit - A large room without walls can increase communication, reduce space, reduce meetings, and make bottlenecks visible.
• Lean Blog: Mental Models: Standardized Work and Performance Measures - Standard work and performance measures mean different things in a traditional command and control organization versus a lean organization.
• Flinchbaugh: Small-i ROI as Applied to Strategy - Sometimes instead of focusing on the big R in ROI, it can pay to find a unique niche requiring just a small i.
• Shmula: Your Baby is Ugly - It happens with babies, it happens with business.  Sometimes you become so invested in your idea or mindset that you fail to see the truth.
• Gemba Tales: Developing Leader Standard Work - Five Important Steps - key components of leader standard work.
• Lean Thinker: Using the Questions - Stay on track by holding to the five coaching questions.
• A Lean Journey: Personal Kanban Kaizen - Tim continues his quest to develop and refine a visual kanban system for his personal projects.
• Lean Reflections: Choosing Online Collaboration Tools for Teams - in the end it's not the tools, but the thinking.
• Curious Cat: Managing Our Way to Economic Success - some great words from John's father on two great untapped resources in an organization: potential information and employee creativity.
• Evolving Excellence: To Shingo or not to Shingo? - The second of two posts discussing, again, the impact of diluting the Shingo Prize with regional awards and "not quite a full Shingo" medallions.

It doesn't matter how much experience you have, what your title is, or whether you are considered a leader in the team / project / company. If you don't know yourself and when you need to ask questions, you're going to be in trouble. You must be able to evaluate your own perspective and whether or not you are stuck down in the weeds or not.

  I’m mapping individual trees, not surveying the forest

I just got off the phone with a coworker who is the 'point person' on a new feature set. I called him and asked for advice on two separate issues related to the piece that I am currently working on. 1) a design problem with the workflow, and 2) whether or not i should "do it right" or "get it done".

My own perspective and involvement in the process had led me down into the weeds of implementation detail where I needed to be. I recognized an issue in the implementation that was causing problems with the workflow. I also recognized that my current depth and focus were preventing me from seeing the big picture (schedule, budget, etc). My reaction to the design problem was one of “do it right” because I was focused entirely on the implementation issues at hand. I knew that I needed a higher level perspective to understand whether or not “do it right” was the correct response, though. So, I called up my coworker and asked for help. We discovered two possible solutions through the conversation. One of them was “the right way” to make the code conform to all of the principles and patterns that we try to use. The other was “well, you could just do this and get it done without a major rewrite”, ignoring many of those principles.

 

Lose the ego and the pride

In the end, I was not capable of making the decision to “do it right” or “get it done” because I was too far down in the weeds of implementation detail. I needed a different perspective and advice on how to proceed and I found that perspective by asking questions and seeking advice. 

I don’t care about my title, role, or over-arching responsibilities on the team, the project or within the company. It would have been irresponsible of me to assume that I could make the decision on my own at that point in time. This does not mean that I always have to seek advice and others’ perspectives. It only means I know when I need to seek advice and others’ perspectives. It also creates opportunities for me to take the opposite role on a regular basis. I am often the person with the high level perspective who is capable of providing advice on whether or not someone else can take the time to “do it right” vs “get it done”. And because I know when to ask and I do ask when I need to, others are also willing to ask because they see that it’s ok to ask.

If you refuse to ask; if you don’t know when to ask; if you are afraid to ask; you are potentially damaging your career, team and project. Lose the ego, drop your guard and give up your pride for a moment. Learn when and how to ask for the help that you need.

Entry by Adam Monago

Entry

Software teams, in the broader sense, are complex adaptive systems.  They live within organizations populated by many actors, influenced by the methods, practices and behaviors that coexist with them.  Most of all, they have the capability to learn and adapt to each new entrant into their world.  It is for this reason that, we tend to avoid recommending ‘best practices’ that all software teams can follow for success, let alone ‘agility’.

At ThoughtWorks Studios, we have defined our ideal state as being one of continuous delivery: one in which the customers and users of software have maximum ownership and influence of the development process.

Read the full article at Tech Journal South (http://www.techjournalsouth.com/2010/09/best-practices-for-adaptive-software-teams/)

Keywordscontinuous delivery, adaptive software teams, continuous deployment

We had a great session this past August as we learned a new estimating technique (mainly for speed estimating) and understood a higher level what Epics are in the Product Backlog. Gary McCants and Don McGreal did a great job presenting and facilitating the meeting. Many of you requested the presentation, so I have posted [...]