Agile Project Management—No Upfront Estimates!

I’ve been managing software projects for much of my career. Early on, I spent most of my time trying to estimate projects more and more effectively. I pulled together models for how to estimate. I kept track of historical estimate vs. actual data, so that I could evaluate the quality of my estimates. I even tried some modeling or arithmetic techniques to fine tune my estimates. Some of these are quite well know techniques like Function Points or Cocomo or the Personal Software Process.

Agile Project ManagementAll of this was focused towards estimate quality…not software product quality. I was worrying about how to represent the time to build the software to stakeholders and accountants so that we could reasonably know how much it would cost. Then we could make better decisions around whether to start it or not.

The odd thing, at least in my experience was that no matter how hard I tried nor how much effort I expended on estimation and planning, over 60% of my projects went awry. They failed. They were Death Marches. They were incredibly painful. And in many cases, they resulted in people losing their jobs.

I guess my point is—estimation is incredibly hard.

Now you may say, well Bob, you simply were poor at estimation and didn’t really perform it all that well. My counter is that I am really good at estimation. I’ve studied a wide variety of techniques and applied them diligently. I’ve even taught software estimation at international conferences. So, while I still have much to learn, I’m not a tool-less novice.

And I guess my other more crucial point is—estimation was the wrong place to be focusing my efforts!

What the Agile Methods Taught Me

When I first was introduced to the agile methods I was struck with the practicality of the planning. Instead of focusing on planning & estimation, the methods broke things down into two levels—high level release forecasting and low level detailed iterative planning. More importantly, it was the interplay between these two levels over time that refined your estimates.

No longer did you try to predict a guaranteed endpoint for a project. Instead you gave a reasonable, high level view that you promised to refine every time you got real-time performance results from your team. You would then narrow your view over time as you iteratively gained traction delivering real, working software. At each point of actual data, you would update your release plan / model and re-communicate to stakeholders where things actually stood in relation to their expectations and your previous views.

If you were behind schedule, stakeholders had the option of dropping, reducing, or re-framing scope based on business value and priority. But in order to hold to a date, they would have to adjust something. If you were ahead of schedule, a not so rare event, they could pull in more value-based scope and deliver more than anticipated.

High Level – Release Planning

The methods don’t spend a lot of time estimating in excruciating detail at the high level. Instead you estimate work (usually expressed as User Stories) in generic level of effort/complexity units (usually expressed as Story Points) so that you can plan the number of stories you can fit into a series of sprints to meet a content commitment for your stakeholder.

Remember, release planning isn’t a firm commitment. Nor is it exhaustive, detailed planning. It’s a best guess, high level view to packing work into iteration sized time-boxes. However, there’s a missing point to accurately planning a release. What you might ask?

It’s the teams’ own velocity. Put another way, the teams’ ability to execute and deliver fully done stories within your iteration time-box. The first time your team actually delivers work from a 2-week sprint you have a wonderful data point—actual team velocity! Please don’t undervalue it.

Low Level – Sprint Planning

But I got a bit ahead of myself.

In the agile methods, where does the team dig into the details? Refining tasks, looking at dependencies, breaking things down into smaller, quantified (hourly) units of real work to be completed? They do that on an iteration (Sprint) by iteration basis—grabbing a small “chunk” of the work, always the highest priority and most urgent work, and breaking it down for the very next Sprint.

If you ever get the chance to attend a proper Sprint Planning session, you’ll have transparent access into a software team breaking down work into very small tasks. You’ll begin to understand all of the complexity and nuance for each story. You’ll hear the testers challenging the developers on testability and how challenging this piece of code will be to test—which will add more tasks for testing and quality.

If the team feels a more detailed design is required, you’ll hear them discuss it. How much? Who should be a part of it? And what does the review look like? Etc.

In general, you’ll experience all of the complex gory details of software development—the real work involved for a single sprint. Then they’ll do something wonderful. They’ll commit to the work and deliver what they can (fully done) at the end of the sprint. You’ll now have an actual data point for the teams’ capacity that you can compare and contrast against the overall release plan—with full transparency into the plans and details and with no extra padding allowed.

How cool is that?

Wrapping Up

I do quite a bit of sharing on agile methods nowadays—via presentations, formal training, and coaching. Believe it or not, I often get challenged on some critical aspects or techniques surrounding agile. None more than the point being made here.

The challenge goes – “There’s no way my boss will put up with a non-committed date for a project” or a “We’ll know how long it will take when we see it” approach to project estimation will not work in my company because we live in the “real world”.

My counter then is usually the same—“Fine, do what you’ve always done”. Try to predict the future on a highly complex software project without doing any real development. If you can guess correctly, then great—stick with your practices.

BUT, if you notice that you often fail. And by often I mean 50%, 60%, 70% or even 80% of the time to successfully meet your stakeholders expectations, THEN you’re practices are clearly not working for you.

Admit that and try something a bit different. Agile Project Managers make the above approach work every day in a wide variety of business, customer, and technology contexts. It’s no longer a bleeding edge technique! It simply drives more real-time transparency into project progress. It helps with adjustment based decision-making. And it leads to more collaborative and successful outcomes.

From my perspective, if your methods aren’t working that well for you then what do you have to lose? So, what DO you have to lose?

About the Author: 

Bob Galen is the Director, Agile Practices at iContact and founder of RGCG, LLC a technical consulting company focused towards increasing agility and pragmatism within software projects and teams. He has over 25 years of experience as a software developer, tester, project manager and leader. Bob regularly consults, writes and is a popular speaker on a wide variety of software topics. He is also the author of the book Scrum Product Ownership – Balancing Value from the Inside Out. He can be reached at bob@rgalen.com

Posted in: 
PM-Agile

Adventures in Publishing Land

I like playing by the rules. Not because I'm paranoid or anything. I just don't find a lot of fun in breaking the law. So when I heard a song on the radio that I wanted to use as background music for a video to post on YouTube, I knew I needed to get the rights to use it first. This was the first time I'd tried doing something like this, so I went at it blindly and followed a logical and very down-to-earth course of action--

Publishing LandOver the bridge to Publishing Land.

First, I searched for the song on YouTube and followed the link to the band's channel. The fairies of Pandora were singing happily along as I waltzed on from there to the band's official website. And froze.

The website was in Italian. I don't speak Italian.

Through the flowery field of Facebook.

Thank goodness for social networking. An Uncle of a friend of my Dad's helped me translate my letter into Italian. After employing the help of the generous and almighty Google to find a contact email for the band-- I sent it to them. Ciao, II mio nome è Garbers Annika, una ragazza di 13 anni, --etc.



Wading the swamp of endless research.

A day later, I received an email back.

“Ciao Annika, for this song you might want to ask for permission to the record company who has the rights for USA. All the best.”

Oh...

Search engines are tricky creatures. They seem to know whenever you really want to find something, and then they hide it from you. Mischievous little things. After attempting to persuade the ones on the record company's website for several hours, they finally showed me a PDF form to download and fill out. It had all sorts of questions about the “Production Budget” and “Exact Description of Scenes”.

I sank dumbly back into the comforting pillows of mildly amusing Vimeo videos for awhile, and then got up again and started filling out the form. I put $0 for the budget question... hoping that would be acceptable. This was just a video of one of our robotics competitions...

The forest of faxing and phones.

At the bottom of this form, it instructed you to fax it (erm... I don't remember ever faxing anything before...) to a certain number, along with a written letter of approval from the music publisher.

I had no idea who the music publisher for the song was... Again to consult the great Google!

I found.... a phone number. I called it and the person who answered gave me an email address to contact.

Sinking into the canyon of fails.

I sent my letter again – the English version this time – and waited.

And waited...

I never got a response back. Two weeks later, I finally gave up. I emerged from Publishing Land, my metaphorical feet worn out, my real-life head aching.

The lesson I learned – stay out of music licensing, little girl, because unless you have lots of experience, lots of time, and lots of money – there's no point in even trying to do the right thing.

A few days after my interesting little pilgrimage, my dad mentioned something about Creative Commons licensing. Since I was running out of tracks to use on the royalty-free music CD I had, and using other stuff seemed to be out of the question, I took a somewhat cautious stroll into the less-widely-known Creative Commons Country.

And fell in love.

The idea of CC licensing was created by passionate people who want to share their work with the world, without the crazy jumble that is record companies and music publishing. For a lot of people, and for me - this is an amazing resource. The different varieties of licenses are specific but easy-to-understand, and it's clear exactly what you are and aren't allowed to do with the music and what's expected of you.

I can understand why Publishing Land is so complicated for people who are making huge, high-budget movies or commercials, but, as far as I can tell, there's no golden bridge over the swamp if you're just a kid who wants to stick a video on YouTube.

So – I'm left here, in Creative Commons Country, happily discovering more and more music I love, and with a great appreciation for the people who created this beautiful alternative to the confusing and complicated Publishing Land.

About the Author: 

Annika Garbers is the co-founder and editor for heyhomeschoolers.com and is working on developing a new website for kids and teens to learn about Drupal. She has taught other young people html and css and answered questions about website building from kids all over the world. You can reach her at annika@heyhomeschoolers.com or through her page at heyhomeschoolers.com/content/annika.

Posted in: 
Development

SQL 101 - Select

The first thing you need to know when learning SQL is how to get data out of a database. This means learning the SELECT command. Using this command will get the SQL server to return data to you. You can use this command to do some simple math, or to do the common "Hello World!" application you all learn the first day of a programming course.

SELECT 1 + 1
> 2


SELECT 'Hello World'
>Hello World


Keeping this in mind can become useful later, when you need to have the server return debugging statements to you during particularly long code writing sessions. Usually you'll need the SELECT command to look up a certain piece of data from a table. The following examples are going to work from the AdventureWorks database. SQL 101You can install this database on your own instance of SQL, or you can contact me and I'll give you access to my test server. This is a new service I'm offering to anyone who wants to learn SQL!

In the AdventureWorks database, there's a table used to store products created/sold by this company. It's called Production.Product. (for now, let's ignore the fact the table name has two parts...I'll explain that later!) In this table there are several columns, one of which is product's name.

If you wanted to get a list of the name for every product in this table, you write the following command:

SELECT
     Name
FROM Production.Product

SQL Table 1

This is just the first 4 items that showed up when I ran the query. You may see different names appear in your list. My data has been updated by myself, and other students accessing this database.

I'd like to point out the data returned is not ordered. In later articles I'll show you how to put the results into any order you may find useful. But for now, Let's stick to learning about the SELECT statement.

What if you wanted to know the name and the price? In SQL you can list as many columns as you like, in a comma separated list.

SELECT
   Name, StandardCost
FROM Production.Products


SQl Table 2

This is the first 4 results I received.

Finally, if you want to return all the data of the table, you can do that too. But I would like to point out using the following command on a table with lots of rows (thousands, or millions) could be very time and processor consuming. Use this only if you know the number of records and columns will be small enough your server and connection can handle. There are also many reasons NOT to use this, most of which have to do with the fact SQL is a shared resource... asking for all the data causes your server to work harder for you, and as a result, there are fewer resources left for other users.

Use the SELECT * queries sparingly!

SELECT *
FROM Production.Products

SQL Table 3

There are more columns off to the right, but I've cleaned up the output to make it easier to read.

As always, if you have any questions, please let me know! I'm here to help you understand SQL better. Let me know how I can do that. Play around with multiple variations

About the Author: 

Look no further for expertise in: Business Analysis to gather the business requirements for the database; Database Architecting to design the logical design of the database; Database Development to actually build the objects needed by the business logic; finally, Database Administration to keep the database running in top form, and making sure there is a disaster recovery plan. Connect with Shannon Lowder.

Posted in: 
Development

Going All Google

Have you ever gone to Google.com just to see what the "Google Doodle" of the day is?

I have. Numerous times. My most favorite ones were when Google paid tribute to Les Paul, and when they celebrated the 30th Anniversary of Pac Man. You can see a full list of doodle's here.

I love that concept. Taking a logo and letting loose a little. Not being so starchy with your "brand."  I was recently given the green light by our Marketing Manager to "have some fun" with our logo. Pulling in some of our graphic designers, I asked them to create different designs that we could use throughout our social media sites.

What they came up with was using the "M" of MATRIX and giving it life. So over the past few months, our M has celebrated several holidays, honored our country, and even gave a glimpse into "her" heart as a Mother of a little "m".

I know you're not running to your computer daily to see what the new MATRIX "M" is, but I'm sure you have a favorite. Or maybe you have a clever idea for a design, I'd love to hear that too! 

Leave a comment, and let us know which is your favorite MATRIX "M".

The MATRIX M's

About the Author: 

Adam Waid is the Director of Marketing at Mediacurrrent, an industry-leader in helping organizations architect custom Drupal websites. Adam is also a MATRIX Alumnus, where he worked closely with the Sales and Recruiting organizations to develop differentiation strategies, create content, and drive CRM and social media initiatives with a single goal in mind - build stronger, more meaningful relationships with our clients. Leveraging new technology, the latest social media trends, and a good mix of traditional marketing, Adam grows online communities.   Follow Adam on Twitter and Read his Social Media Blog.

 

Posted in: 
Fun

8 Steps to a Bad Hire

So you’ve been charged with a hiring a new employee for your team. You want to do it right and end up with a great person (although you secretly think hiring is really an HR responsibility and wish someone over there would do it for you). As a matter of fact, it occurs to you that you’ve never actually been taught how to interview and hire someone, so how are you supposed to know how to go about it? And let’s not even get into how busy you are with more important projects—you really don’t have time for this. Maybe if you screw this up, someone else who can do a better job will snatch this responsibility back and do it next time.

Hmmm… So what steps can you take to make a bad hire? Here are a few to get you started:

Now Hiring#1—Have no clue what you’re looking for.

Don’t bother to update or create a job description for the open position. Avoid wasting time putting together a list of the skills, experience or personality traits the position requires. Trust that your gut instinct will tell you when you’ve found the right person.

#2—Don’t waste time on recruiting.

Just post the opening on Monster or CareerBuilder and see what rolls in. Wait around for someone in HR to screen the flood of resumes you get in response to your posting and complain that “they” aren’t finding any good candidates for you.

#3—Make a lousy first impression.

When you finally do find a few candidates that seem promising, invite them in for screening interviews but don’t worry about impressing them. Make them wait, scramble around to find an empty conference room for the meeting, look over their resumes with them sitting across the table from you. Feel free to take calls and check your Blackberry during the interview as well.

#4—Talk too much.

In the interview, spend the majority of the time telling the candidate about yourself, your history with the company, your accomplishments, and your plans for the future. Then move on to explaining at length what the open position entails and what type of person you’re looking for to fill it. Spend only the last few minutes of the interview asking questions to learn about the candidate. Assume he didn’t do a very good job presenting himself if afterwards you feel like you really don’t know anything about him at all.

#5—Ignore any and all red flags.

If you really like a candidate or if you’re especially desperate and are down to only one or two people to choose from, pay no attention to any troubling signs. She’s already asked half a dozen times how soon she’d be eligible for a promotion if she gets the job? So what. Some of his answers to interview questions have been inconsistent with what’s on his resume? Big deal. Probably doesn’t mean a thing.

#6—Don’t bother with reference checking.

Or if you do, only call those people on the “List of References” the candidate provides. After all, surely those people know the candidate best and will be completely objective in discussing both her strengths and weaknesses. That’s why they’re on the list in the first place, right?

#7—Focus only on the job.

Keep top of mind that whether a candidate fits with your open position is the only thing that matters. It’s not at all important to consider whether he’ll fit with the rest of the existing team or with your management style. And don’t worry a bit about whether he’ll mesh with company’s culture and values. That will all work itself out after the fact if you end up hiring him for the job.

and finally,

#8—Count on being able to change people after you hire them.

Don’t be concerned if the candidate you end up choosing doesn’t have everything you need—that’s what training is for. Doesn’t like to take initiative or work independently? No aptitude for handling conflict? Can’t seem to figure out how to get along with others? Hates having to follow specific systems and procedures? You can fix all that later, especially if the areas are related to personality traits or innate talents, since those are especially easy to alter in others.

So there you have it. You might not need all of these tricks, but even a few of them, if used correctly, can pretty much guarantee a bad hire. They’re all easy to implement and have been proven countless times to be successful. Give them a try and I predict you won’t have to worry about being expected to select your own team members too many more times in the future.

What’s missing from this list? Anything else you’ve found reliably leads to a bad hire? Please share your thoughts in the “Comments” section.

About the Author: 

Janna is Vice President of Client Services for The Berke Group, where she leads their education initiatives and serves as their key client advocate.  Berke provides powerful assessment software that measures personality, talent, and intelligence and helps companies hire the best people.  Janna develops Berke’s  learning programs and provides both on-site and web-based management training for companies and individuals. She also writes about people management strategies, trends and best practices.

Posted in: 
Hiring Manager