Tag Archives: Agile

3C’s of Measurement Success – Create, Confirm, Convince


I recently recorded the remote meet-up presentation I did for Ryerson College (Toronto, Canada) called 3C’s of (FSM- Functional Size Measurement) Success – Create, Confirm, Convince.  The focus of the presentation was about how to position software measurement for success with management – especially in the context of agile software development.

Advertisements

What is this Thing – the Heart of Agile – all about?


If you’re an agilist (my word for those who embrace agile concepts to do great work) – you’ll be interested to hear about the Heart of Agile directly from the mouth of its founder Dr Alistair Cockburn.

Join me TOMORROW (Thursday Oct 4, 2018) at 10:00am Eastern Daylight Time as I interview Dr Cockburn in St Petersburg, FL about the new Heart of Agile and where it fits into the landscape of Agile Software Development.

Here’s the link (recording will be posted later if you cannot access Facebook!)

No automatic alt text available.

https://www.facebook.com/events/364530300951242/

p.s. Here’s the link to the website under development:  https://heartofagile.com/

Join me!

Carol

The Death of Brainstorming? Say it isn’t so…


I love the articles in the New Yorker, and the following one caught my eye because of the Brainstorming topic. In leadership courses, I’ve espoused the value of brainstorming when done right (without judgement and analysis) – and I’ve seen positive results.  Could it be that the creative process might actually work better when criticism is allowed to fly?

Say it isn’t so

When I teach brainstorming techniques, I always find it interesting that the creative (right brain dominant) thinkers in the group really love and contribute more during the “Brainstorming” free flow of ideas phase (before analysis sets in), while the linear, engineering style (left brain dominant) thinkers in the group can’t wait for the second phase where the ideas are analyzed and critiqued.  Divergent thinking followed by convergence of ideas.  Made perfect sense to me and the students demonstrated how safe each group felt – depending on which side of the brain dominated their idea flow.

So now, it appears that the “Steve Jobs” style of criticism before acceptance, domineering boss-like, judgment first ways of working have merit, or do they?  Read the article then read on and comment (please!)

Here’s the link to “Groupthink” if you cannot reach it above.

I’m conflicted…

about this latest “research” and given my international experiences in presenting in over 30 countries to technical audiences, I have to say that Information Technology and software development are as much about the people and psychology (trust and communication) as they are about technology and engineering problems.

I’ve seen success with collaborative approaches like Kanban, agile, Rational (Use Cases) – which I believe succeed because we bring disparate viewpoints of the customers and suppliers together and address various learning styles (visual, audio and kinesthetic) to gain the highest levels of understanding.  Brainstorming is one such technique whereby the most dominant (i.e., typically the most critical of all ideas except his/her own) no longer gets to direct the problem solving.

What’s BEEN your experience?

I look forward to your comments – do you agree with these findings? – and to further research… and to hopefully announcing that Brainstorming is NOT dead, in fact, it just needed a wake-up call to re-energize the benefits for a new iPad generation!

Technology at the Speed of Sound… Catch up at Light Speed at LSSC11!


I have to admit that I have not programmed a computer for many years and I have no idea how to write Visual Basic or Java or dot net.  (Yes, I have done raw html and could still manage in SAS if I had to!)

And I can also admit that the proliferation of models and methods from Agile, Scrum, Kanban, Lean, Six Sigma, Xtreme Programming, CMMI(R) (Capability Maturity Model), to manifesto driven systems development,  has me daunted.

Which ones are interchangeable, which are compatible, which are contradictory, and (OMG) where should one start to learn how to avoid the pitfalls?

It’s all a matter of diving in to each and learning the ins-and-outs and best practices — except I know that there are as many opinions about best practices as there are models.

Okay, I can already hear you saying:  “Carol, as a software measurement/Function Point Analysis and PMP (Project Management Professional), you probably don’t need to know much about any of these” — except that I do!

My clients will ask me about these and other emerging topics – and expect that I know the best course of action they should take with Lean/ Kanban/ Agile methods for their company.  And I simply do not have spare time to read all the books, experiment, fail, try again, and then decipher what is hype and what is real in this space!

So what is a sane, intelligent, forward thinking IT professional like me to do when faced with an overwhelming mountain of information like this so I can properly advise my clients?

The answer is: ATTEND the Lean Software & Systems Conference 2011 (#LSSC11)!

There is no other conference in the same timeframe that offers more than this growing conference!

Being held 3-6 May, 2011 at the Hyatt Long Beach in Southern California, this annual conference boasts over 90 speakers over a 3 day period on topics ranging from:

See the full program at http://lssc11.leanssc.org

All given by practitioners and experts for practitioners!  And the majority of presenters have real world, hands-on experience in the trenches with Kanban, Lean, Agile and Scrum and lived to tell about it!

Why not catch up to technology racing at the speed of sound by accelerating your learning Light Speed with LSSC?

There is no similar conference offering the breadth or depth of topics, experience sharing, or real case study results in the Kanban and Lean software development space.

And the May 5, 2011 Brickell Key awards for excellence in the advancement of Lean in software development will recognize some outstanding nominees working in the area – some of which are professionals just like you!

I know that I will catch up on these major topics and more – in record time – by attending LSSC11.  If you are an IT professional, don’t you owe it to yourself to check it out?

Read about the Program and the Speakers at LSSC11 and register today!

Wishing you an eventful and productive week and I hope to see you in Long Beach on May 3, 2011!

Regards,
Carol

Share

Whose job is IT anyways?


The title was a purposeful play on the acronym “IT” (information technology) because there is often no one person who takes responsibility for failed IT projects. In addition, it is not as if there are not project failures everywhere.

Notwithstanding one of my least favorite (but often quoted) research studies, the Chaos Report cites that about one-third of projects are successful when it comes to IT.  What gets in the way of project success?  Lots of circumstances and lots of people!

When a software intensive project fails, there is no lack of finger-pointing and blame sharing – yet seldom do teams stand up and confess that the failure (over budget and behind schedule and failing to meet user needs) was due to a combination of over and under factors, along with fears:

  • overzealous and premature announcements (giving a date and budget before the project is defined);
  • over optimistic estimates of how quickly the software could be built;
  • under estimation of the subject complexity;
  • assumptions that the requirements were as solid as the customer professed;
  • under estimation of the overall scope;
  • under estimation of how much testing will be needed;
  • under estimation of how much time it takes to do a good job;
  • under estimation of the learning curve;
  • under estimation of the complexity of the solution;
  • under estimation of the impact of interruptions and delays;
  • over anticipation of user participation;
  • over optimism about the availability of needed resources;
  • over optimism about hardware and software working together;
  • over optimism about how many things one can do at once;
  • risk ignorance (“let’s not talk about risk on this project, it could kill it”);
  • over optimism of teamwork (double the team size doesn’t half the duration);
  • fear of speaking up;
  • fear of canceling a project (even if it is the right thing to do);
  • fear of pointing out errors;
  • fear of being seen as making mistakes;
  • fear of not being a “team player”;
  • fear of not knowing (what you think you should);
  • fear of not delivering fast enough;
  • fear of being labeled unproductive;
  • fear of being caught for being over or under optimistic.

Therefore, I ask you, on a software intensive IT project, whose job is it to point out when there are requirements errors, or something is taking longer than it should, or it is costing more than anticipated. In traditional waterfall development because there’s so much work put into the planning and documenting of requirements, pointing out errors are  either no one’s job or the team’s (collective) job which really relates to no one’s job.

Often it is easier (and results in less conflict) to not say anything when the scope or schedule or budge go awry on a software project. Yet it is this very behavior that results in so much rework and so many failed projects.

Agile and Kanban projects are different

Several of the advantages to using Kanban and Lean and Agile approaches to software and systems development is that the methods address the very items outlined above.  Building better software iteratively becomes every developer’s job rather than no one’s:

  • Fear of pointing out errors is removed because the time that goes into a scrum is days and weeks not months (so participants don’t get defensive about change);
  • Over and under optimism remains but is concentrated on smaller and less costly components of work (i.e. days instead of months or years);
  • Risk is not avoided or ignored because we are no longer dealing with elongated and protracted development cycles (spanning seasons);
  • Assumptions come out with better and more frequent discussions;
  • Over optimism about how many things one can do at once is removed because Kanban limits the amount of work-in-progress;
  • Under estimation of the impact of interruptions and delays is minimized because such factors are addressed in Kanban;
  • Over anticipation of user participation is managed through direct user involvement.

What do you think?  Join us at the Lean Software and Systems Consortium conference LSSC11 from May 3-6, 2011 as participants and speakers address the best ways of advancing software and systems methods including Lean, Kanban, Agile and other exciting new ways to deliver high quality software more efficiently and effectively.

These newer approaches make it easier for everyone in IT to make it their job to build better software.

Wishing you a productive week!

Carol
@caroldekkers (twitter)

Share

The importance of Being There (at work)!


Did you know?

Only 26 percent of IT employees in North America are fully engaged at work, while 22 percent are actually disengaged, according to a global study by consulting firm BlessingWhite.

Being there…

At a time when unemployment is at an all-time high, only one-quarter of IT workers are fully engaged or Wowed by their work, while the remaining 75% just go through the paces or don’t care at all.  When you consider specific industries fraught with frustrations of rework (exceeding 40% in some areas) and impossible deadlines such as in waterfall development, I would bet the excitement factor of going to work is even less.

#Kanban, #Lean, and #Agile communities are exceptions

The Agile Manifesto recently celebrated its 10th anniversary last month, and Kanban, Six Sigma, Lean, and Agile methods now share space with waterfall as leading methods in the software and systems development space.  Agile (in my humble opinion) was one of the first to restore a sense of sanity in software development.  In earlier times, a group of  business customers with rapid fire changing requirements would challenge software developers (tired of the constant change and “jello” like demands) for amorphous software products.  The result too often – failure.

It makes sense, in this type of environment, to do iterative development.  It was illogical to do the opposite: long development cycles to produce products already obsolete before they hit desktop computers.

Approaches like Kanban, Lean, Agile, Personal Kanban and others continue to transform our industry and inspire software developers to become “fully engaged” in the work.

Less head banging… but you have to engage

Certainly there is head banging and more job satisfaction in this new world (if “tweet volume” is any indication, the Kanban/ Lean/ Agile communities are a happier lot!) but it takes commitment to show up and be part of the action.

I believe that the Kanban and Lean and Agile communities know the importance of really being present and engaging at work.  We also know it is critical to create a community of like-minded people who meet in-person – at conferences, local meetings, at social events.

LSSC11 is coming soon!

The landmark Lean Software and Systems conference is only 10 weeks away in Long Beach, CA on May 3-6, 2011.  Make your choice of conference to attend in 2011 the LSSC11 (especially if you can only attend one!)  See my related post Top 10 Reasons to attend LSSC11.

Join the movement of people who know the Importance of Being There in software and systems development: The Lean and Kanban and Agile communities.  I hope I will meet you at LSSC11!

Have a Wow! and engaging week at work,

Carol

Share

WTP?* No more methodology battles…


Ever since my college days (many months ago!) there has been a “situation” concerning IT and the business.  Despite a plethora of new methods, technologies, software, and business-focused efforts, the valley of communication between IT and the business remains. Sure, there has been progress – business analysts, project management, agile development, Kanban and others have brought the customer to the table (so to speak) with software developers, but the gap remains.

Just today, a colleague in the Kanban / Lean development space remarked on Twitter:

Master servant“I think IT and business are stuck in a master / servant relationship as opposed to a trusted partner one.”

It seems that the more that things change, the more they stay the same… and it is frustrating. There is so much work to do in terms of communication, education, soft skills to bridge this gap.

So WTP* of methodology battles?

Really, WTP (What’s The Point) of methodology battles in software development? I see it all the time in cyberspace and at conferences:

  • Function points (and flavors within) versus lines-of-code versus story points versus use case points;
  • CMMI® versus SPICE (a European framework);
  • PMI (Project Management Institute) certification versus IPMA (International Project Management Association) versus Prince 2;
  • Kanban versus Agile versus Scrum versus Waterfall?

Perhaps it is human nature to pick battles we think we can win (as opposed to looking at the overall bigger challenge of the business / IT dysfunction), but What’s the Point?

When you come down to it, a Win/Lose result in software development (along the lines of schoolyard “My mother is smarter than your mother”) ends up being a Lose/Lose for everyone involved. Emotions flare, tempers rise, and time is wasted.  In addition, when you consider the bystanders (other professionals and executives) watching these methodology “catfights”, it’s no wonder many of them step back and retrench without a second thought about ways forward.

Case in point – the function point wars fueled by assertions of “my way (of counting) is better than yours” or “ours is a 2nd generation method while yours sucks” is a pitiful battle proposition when one considers that a mere 10% of organizations measure any software development at all.  Yet the battles go on fueled by notions of superiority and self-congratulation.  (It is no wonder why some organizations forego function points altogether.)

I see the same battles brewing in the Kanban, Lean, Agile, RAD and Waterfall communities.  While each approach offers its own advantages and strong points, none is a panacea and in fact, a diversified team of qualified practitioners can often blend practices to increase output and quality.  When allowed to co-exist in relative harmony (with the goal to deliver better software, reduce rework, and delight customers) – the results could be stellar.  But, we’re not there yet.   I can imagine that when the power nailgun was introduced into construction, it probably faced the same resistance as modern methods have in software development.  Of course, since human beings and professional credibility is involved in both industries – opinions emerge about the best way forward.

No matter which “camp” or area you adhere to in software development, there is no silver bullet or Swiss Army Knife.  We have to learn to lay down our petty differences and work together for the betterment of our customers – and over time, maybe our customers will take notice that we are collaborating for them.

LSSC11If you agree with the notion of collaborating and learning about how professionals are integrating these various approaches (and others) together, be sure to attend LSSC11 (sponsored by the Lean Software and Systems Consortium) being held May 3-6, 2011 in Long Beach, CA.

I can promise you’ll see Kanbaners, Agilistas, Scrumbies, Sigmalites, and even a few Waterfallers working the space networking, sharing, and gently sparring (in jest) – all for the advancement of our industry.  Why not plan to join us?

Carol

Share

There’s no time for “One of these days is none of these days” in IT


Let’s face it

– an investment in software development can be one of the most expensive and medieval timesrisk-laden endeavors a corporation can make, especially when requirements volatility and uncertainty are part of the mix.  In medieval times (of software development this would be pre-2000), customers and developers often jostled over requirements and clashed on issues of flexibility during strict waterfall development.  Then after months of protracted requirements discovery, the construction process would be frequently disrupted by “unanticipated change”.

Fortunately, for everyone involved, innovative techniques flexible to change and offering shorter, more iterative delivery cycles emerged.  Today, a myriad of choices exist that embrace flexibility and deliver high-quality software more effectively and efficiently than ever thanks to agile, XP, scrum, CMMI, project management and other concepts.  Additionally, methods that worked well in other industries have been adapted and tailored for use in IT (six sigma, kaizen, TQM, theory of constraints, just-in-time, Kanban, etc.).

A few of the most fundamental

yet simple concepts of Lean/Kanban/Just-in-Time development (and other methods) include minimizing waste (non-value added activities), removing roadblocks/delays and limiting work-in-progress (WIP).

If we consider software development as a “pipeline” of constant flowing work packets, any unresolved blockages can end up clogging the entire system.  As such, when life intervenes (as it always does) to interrupt or delay the flow of a work packet, approaches such as Kanban  highlight potential blockages before they clog the entire flow.  Teams can then identify remedial actions so that the right work is done at the right time, freeing up resources to concentrate on work where they can be highly productive.  Moreover, while waterfall development commonly fills the pipeline beyond capacity (without realizing it), Kanban limits the input stream to match the available capacity.  Once work is actively in the pipe, a critical delay (“one of these days…”) signals trouble and work can be removed (“none of these days”) until such time as it can be productively worked again or triaged to prevent ongoing delays.  If we are serious about reducing waste (non-value added activity) or delays, IT should never tolerate proverbial “one of these days is none of these days” delays in process.

Unexpected events and delays are a natural part of life (and software development).  The difference with Kanban and JIT is that there is a conscious response to bottlenecks and work stoppage rather than panic or blame reactions (OMG!  What do we do now?) typical of waterfall development.

Can Kanban co-exist with Agile development?

I believe so (and perhaps this is the attitude of a naive believer in both).  Can Kanban co-exist with Waterfall development? Again, I believe the answer is yes.  What do you think?

Don’t forget to register (and tell your management to register!) for the upcoming FREE knowledge webinar on January 18, 2011 featuring

LSSC11 Chairperson, Kanban expert and Author:
David Anderson

on Lean Decision Making, January 18, 2011 from noon – 1 pm Pacific Standard Time (3-4pm Eastern Standard Time). Here’s what this FREE webinar is all about:

Lean thinking assumes it is economically better to build a culture of trust in an organization of empowered individuals to accelerate decision-making and shorten lead times than to mitigate risk with bureaucracy and delayed delivery. Understand the economic model controlling the forces of risk, uncertainty, business value, quality, cost and schedule that affect decision-making and process policy setting. This webinar will show how lean thinking can translate into process and policy decisions more closely aligned with business goals.

Register today to reserve your webinar place!

Why not make 2011 the year that you make a difference in the world of software development by getting up to speed on Lean approaches?  Plan to join us 3-6 May 2011 in Long Beach, CA, USA for the Lean Software and Systems conference (acronym LSSC11) – register today!

Carol
Share

What Goes Around Comes Around in S/W Development… Let’s minimize the rework with Lean!


If you don’t have time to do it right, when will you have the time to do it over? (aka Do it Right the First Time).  There has to be a better way (and there is)!

Rework… what a waste (literally)!

Rework is one of the most frustrating aspects of software and systems delivery, especially when you consider that over 40% of IT development effort is spent doing rework (stats hover around 45% according to published reports from the Department of Defense).  Why is rework so high in software development?  There are many reasons including incomplete or unclear requirements, customer changes (since the beginning of the project), and elongated timelines.  Can you imagine what our life would be like if every industry was plagued by this amount of rework?

  • Construction would take two to three times as long to complete (imagine construction without sealed engineering drawings!)
  • Medical surgeries would mean that patients would have to endure multiple operations to get the original job done properly (I can hear the lawyers applauding already)
  • Clothing manufacturers would have to double their prices because of waste due to improperly cut or sewn garments

Few other industries would tolerate this level of rework…  yet IT not only tolerates rework (in the hope of delivering a product that achieves high customer satisfaction), but most projects end up late, over-budget, and delivering unnecessary or incorrect functionality.  Often projects are rushed through when schedule crunches and rework overwhelms them, or functionality or quality is sacrificed to finish on time.  In either case, results include inadequate software product releases, with costly follow-on maintenance to correct poor quality or product deficiencies.

When Phillip Crosby wrote his award-winning book “Quality Is Free”, many professionals mistakenly thought the title meant that there is no cost to building quality into product development. Today we know that Crosby meant that quality pays for itself in the long run – and ultimately reduces product development costs.  Unfortunately, the idea of doing things right the first time is still a pervasive challenge in IT – and not all the blame lies with the software development team.  Rework, poor quality, crunched schedules, inadequate budgets, and poorly documented requirements are a shared responsibility of both the business customers (who need the software) AND the software developers.

Since the mid-1900’s, other industries such as manufacturing embraced evolutionary approaches to reducing rework, shortening development delivery cycles, cutting out waste and delays, and scoping out smaller bits of functionality to deliver incrementally, with transformational results.  Today a handful of the best practices have been adapted and tailored for use in software and systems development and offer similar transformational results to the IT industry.  Approaches like Kanban, LEAN, JIT (just-in-time), and others  make complete sense and increase team morale and the quality of the resultant software products, while reducing waste.

If you’ve never heard of Kanban, Outcome-Driven-Development, Lean Software and Systems Development, or a myriad of other named approaches, you might be out of touch – but you are also in luck, because there are resources available to get you quickly up to speed.

I’d like to mention a couple of notable resources here:

LSSC11-logo1. The Lean Software and Systems Consortium (LeanSSC) is hosting their second annual Lean Software and Systems conference (acronym LSSC11) to be held 3-6 May, 2011 in Long Beach, CA at the Hyatt Regency Hotel. Here’s a few important links that may be of interest:

2. Upcoming FREE webinars:

The Lean Software and Systems Consortium (LeanSSC)is hosting a series of FREE webinars commencing on January 18, 2011 to educate professionals who want to improve the productivity and quality of their IT delivery. Register today for one or all of these webinars.  Here’s the upcoming schedule of topics and dates for the webinar series:

If you are like me and catching up with all the Lean terminology…

I’m going to be posting frequently in the coming weeks and months about concepts, ideas, and general software development related to Lean, Kanban, Multi-modal approaches, and other topics – I hope that these will help you to catch up and help your company leapfrog ahead of your competition in software development.  And, I’d like your comments and feedback on what you think!

I’ll end this post with a couple of (what I consider) essential snippets:

  • Lean Software & Systems Consortium (LeanSSC) is a global, non-profit organization whose mission is to promote and create awareness of Lean Thinking applied to software and systems engineering and associated competencies.
  • From David J. Anderson on Yahoo discussion group kanbandev:  “I’ve jokingly referred to Kanban as “Outcome Driven Development” recently on Twitter. Some people thought I was joking 😉 as the ODD method hardly seems sensible! You are deciding the outcome you want (from a small change). You want code tested early to avoid it going stale. You want it tested while it is fresh in the minds of those who created it. You also want testing exposed as a bottleneck. You want the test bottleneck made visible/transparent/explicit. You seek to do this through a process (or system) change that introduces a WIP limit. Your hope (based on an understanding of theory, so it is a belief based on a scientific understanding) is that by setting a WIP limit you will expose the bottleneck and provoke further discussions that will change behavior, resulting in the outcome you desire. Your leverage point is the WIP limit. The WIP limit is the actuator you are using to stimulate emergent (desirable) behavior.”

Happy 2011 and I hope you’ll pass on this post to others who may be interested.  Join us on one of the Facebook, Plaxo, LinkedIn or other LSSC11 groups.  You’ll be glad you did!

Regards,
Carol Dekkers
Share