Demonstrating leadership when the values of Transparency, Responsiveness, Agility, Collaboration, and Constant Improvement collide with project management reality.
The ngConnect car is a concept car created to show the potential of the next-generation connected devices, in this case, a car. Connectivity is achieved via LTE, a 4G technology being developed by leading telecommunications companies such as Alcatel-Lucent.
The LTE Connected Car initative is involves partners from multiple industries, and include Alcatel-Lucent, QNX Software Systems, Toyota Motor Sales, Atlantic Records, chumby, and Kabillion all working together to develop applications and services under the ngConnect program.
It is incredible how by leveraging common tools and technologies, companies can add a lot of content into the eco-system.
The future truely is connected, and your car can join the fun :) I am sure I am not the only one that is excited to take one of these cars for a test drive!
I am reading a book called “The 12 Leadership Principles of Dean Smith” by author David Chadwick. I found the book buried upstairs in the guest bedroom and decided to give it a read.
The book is written by David Chadwick, a former student and player of basketball coach Dean Smith. Chadwick has distilled what he thinks are the 12 leadership principles that allowed Smith to be one of the most successful college basketball coaches of all time.
I am currently reading the first chapter on the first leadership principle, and I can say that so far I am not super impressed. It is not that the leadership principle of “reciprocal loyalty” is a bad principle, on the contrary, but I am not sure we need a full chapter on the concept.
Loyalty to your team, your management, and yourself is a core quality of a leader, or for that matter of a follower. If you are loyal to your team, it goes a long way to your team being loyal to you. The same goes for being loyal to your boss.
How do you demonstrate loyalty?
You can demonstrate loyalty by:
sticking up for your team and protecting them from attempts to unfairly target or smear them.
treating your team with respect, and go to bat for them when needed even if it means that you need to “go against the flow”
accepting honest criticism and own up to your mistakes, but don’t accept people pointing fingers, nor point them yourself even when it is you or your team that made a mistake.
not talking behind your team's back, scratch that, don't talk behind anyone's back.
All this being said however, make sure learn from the mistakes so they don’t happen again.
If you are loyal to your team, and you stick up for them and yourself, your team will reward you with loyalty in kind by sticking up for you if someone is talking behind your back, or perhaps working late to meet a tight deadline.
So is being reactive a good thing, a bad thing, or something in the middle?
In some cases it is indeed a good thing. Reacting to changing and fluid situations to put the right people and processes in place to solve a problem is a good thing.
Unfortunately being reactive tends to create a feedback cycle if you are not really careful. You get so wrapped up in being reactive, and responding to the needs, wants, and desires of those around you that you stop being proactive because you run out of time in the day.
You start losing sight of the forest as all you see are these trees blocking your way, and sooner or later you hit one of those trees. You hit it hard, and it really hurts, your head starts to swell and you see a bunch of stars, birds, and moons rotating around your head. A perfect storm that rips up all the trees and spins them faster and faster around, creating a massive feedback cycle that becomes harder and harder to break. You are spending all your time dodging trees.
You see, when a team is in reactive mode, and they are juggling requests as they come in from multiple sources, things get missed. Priorities get messed up, you lose sight of the big picture, and worse, your definition of done changes.
You no longer put the fire out, wait for any flare-ups from fires still burning in the root system, and then finishing off with some nice landscaping to restore the beauty of the forest. No no no, when in reactive mode you just stamp out the fire with your feet and move onto the next one as the hair is singeing on your arm.
So how do you break this cycle?
By making behavior internally motivated, not externally.
They are lots of ways to make behavior become internally motivated:
Make sure you create an atmosphere where your team will take a high degree of pride in the work they do (I don't want my teammate to find a bug in my code)
Enable your team to take ownership in your product (I have a vested interest in the success, I suggest features and improvements)
Identify and immediately correct issues before they become a problem (bad behaviors, bad processes)
Invest in paying down the technical debt (No more, hey this piece of code already does it that way so what's the big deal)
Make sure "done" is actually done
etc
Most of the above is related to strong leadership and management and deserve posts all on their own. One quick and relatively "pain free way" is can be taken straight from the Agile cookbooks, change the definition of done. For example, make sure done means that:
All features have been tested by the developer
The acceptance tests have been successfully executed
No regressions in the automated builds
You have checked for memory leaks
You have done some performance testing to make sure you understand the characteristics, and are getting the most bang for your buck
etc
A proper definition of done is crucial to being proactive and not reactive. Sure you still might hit performance issues, bugs, or missing features, but you are now forewarned and forearmed with the information to narrow down any issues, and you can answer something other then “I will have to look into it”, or worse, "I am not surprised".
When working with your teams, make sure that everyone agrees to a complete definition of done, and that everyone buys into the definition.
QNX is up for an award at the Adobe Max conference under the "Mobile" category. You don't get much more mobile then a car. Unless your battery is dead that is, then it is not so mobile until you get a boost.
The QNX CAR application platform in an all encompassing reference platform for building next generation infotainment systems and digital instrument clusters.
Vote for QNX Car at Adobe Max's site today! You can also see other cool applications of Flash technology from the other finalists too.
Yay me! My blog was added as a top project management blog to The Daily Reviewer.
"Congratulations! Your readers have submitted and voted for your blog at The Daily Reviewer. We compiled an exclusive list of the Top 100 project-management Blogs, and we are glad to let you know that your blog was included! You can see it at http://thedailyreviewer.com/top/project-management"
The Daily Reviewer is an an online aggregator of content similar to Alltop, which, incidental I am also on. The Daily Reviewer seems smaller, much newer, and more advertising driven then Alltop.
Looking at their terms, it seems I will have to be more active blogging as they are looking for bloggers to post at least once a week. This is a little more frequent then my blogging patterns have been over the past few months.
Should be a good motivation to get started again :)
In many Scrum teams a practice has emerged to have the Scrummaster role played by a different team member each sprint. The ideas behind this are many and varied:
Rotating the Scrummaster allows more people to learn Scrum in-depth
Each team member adds new ideas to how to run the Scrum project
Builds skill redundancy for the team. If the Scrummaster gets sick, or quits someone can take over without too much lost velocity
Helps empower the team, everyone gets to participate at all levels
Helps prevent people just reporting status to the Scrummaster
etc
But is this really a good idea?
Most of these benefits can be achieved with other means, and some are caused by the Scrummaster doing a poor job at leading the team. For example with number two, that can be accomplished by having a really great and open team atmosphere, or even good, dynamic introspections. You don't need to be "in charge" to bring forward ideas.
Depending on the context I think it could beneficial to rotate the Scrummaster role around. However, not every single Sprint. It makes more sense to allow at least three Sprints to elapse prior to rotating out the Scrummaster. It will take at least three Sprints for that person to get comfortable in their role and get their mind into the Scrummaster space.
Don't force every single person on the team to take on the Scrummaster role! Not every single person has the personality to do the job well and there is no point in setting someone up for failure.
Even if you don't rotate the Scrummaster role around, it is very important for that Scrummaster to train his replacement. People should always be able training one of their peers to do their job. In the military this is institutionalized for very good reasons, but many companies don't factor in the "bus factor" in their contingency plans. This can seriously harm a company or a release cycle.
What do you think? Should the Scrummaster role be rotated? If so what best practices do you have? Or should the Scrummaster role be assumed by one person so that they can master it?
Col. James Moschgat wrote an article about the ten leadership lessons he learned from his janitor at the United States Air Force Academy, an unassuming Medal of Honor winner from the Second World War.
There are some excellent lessons here:
Be Cautious of Labels - Labels don't define people, actions do.
Everyone Deserves Respect - Golden rule stuff.
Courtesy Makes a Difference - Goes with the above rule, respect begets respect.
Take Time to Know Your People - Strengths, weaknesses, motivations, etc.
Anyone Can Be a Hero - Save the day, save the project.
Leaders Should Be Humble - Don't be like "modern" leaders like self-aggrandizing sports heros and the like.
Life Won’t Always Hand You What You Think You Deserve - You need to work hard to get it.
Don’t pursue glory; pursue excellence - Be great at what you do, even if it isn't "sexy", but love your job at the same time, life's too short for anything else.
Pursue Excellence - See above.
Life is a Leadership Laboratory - Examples of great leadership are all around, you just have to look.
Number eight and nine are pretty much the same, I would have pulled the following point into a numbered lesson "No job is beneath a leader". This lesson is one that I can really relate to.
In one particular example, about a year ago, one of the teams I was leading was working on a Java web project that was running a little late. OK, a lot late. The whole team had pulled together to put the final touches on the acceptance build. It was 10pm at night we had to get the build out the door before the end of the day. QC was many timezones away (India) and not yet in the office. We had 3 browsers to test, and only two hours to do this.
The solution was to import that QC test plans into Google docs, then have the entire team run through the test plans collaboratively in real-time. Executing test plans isn't part of a developers normal job, sure they run their own tests, but they not responsible for running sanity tests on builds that are on there way to the customers. But we didn't think twice, we all pulled our socks up and got the job done. Developers, Project Leaders, and Project Managers all worked together to get the testing done.
This allowed us to get the sanity testing done on all the supported browsers done in a fraction of the time it would have taken a single QC person to do it. When the QC started their day a few hours later, they spent their day running their more detailed test scripts against our drop to see if we had missed anything, but the Project Leader and I had confidence that what we were sending the customer didn't have any big functionality or rendering bugs.
When I look back at this example, I see three leadership principles demonstrated:
Lead by example
No job is beneath a leader
Rewarding the team for their sacrifice (reward followers)
Lead by example In this instance I was able to lead by example by implementing functionality and fixing bugs quickly. By submitting good patches, and performing good code reviews. By working nights and weekends for those four weeks or so, I could show that I too was making sacrifices to my personal time, I tried to ensure that I arrived with the team and left with the team during that time. I wasn’t just dictating that overtime was to be done, I was actually doing overtime. After the project, several of the team members came up to me and thanked me for my contribution, and said that it helped motivate them to work extra hard and get the project done.
No job is beneath a leader It wasn't in my job description to write code, review patches, or run test scripts, but I did it anyway because it helped the team accomplish the mission. If someone had to go out and pick up supper from the office, I did it. What was really great was that everyone did whatever had to be done. This was a great attitude to see on a team.
Rewarding the team for their sacrifice I made sure to thank the members of the team personally nearly every night when they signed out for the day. At the end of the project I made sure they were compensated for their time, and provided little thank you gifts to everyone. Doing a few little things to thank them for their time and effort can mean a lot.
When projects run late, teams can easily get de-motivated, leading by example, doing whatever it takes to finish the project even if it’s “beneath” your position, and showing appreciation for the team’s sacrifices are three ways that can help show the team that you are with them and that you support them.
Remember that leadership is about influencing people, hence it is more of a service then a command. You need to influence your team to go the extra mile by being a good leader that your team will look up to, and be inspired from. These three principles honestly applied can help you become that leader.
Patricia Sellers posted an article up on her blog a few days ago about David Ogilvy, called by some "The Father of Advertising". In the article she shares the business advice David once told her. All of these are great, most of them strike to heart of humanity and leadership. Here are ones that relate most to me:
Remember that Abraham Lincoln spoke of life, liberty and the pursuit of happiness. He left out the pursuit of profit.
Remember the old Scottish motto: “Be happy while you’re living, for you are a long time dead.”
If you have to reduce your company’s payroll, don’t fire your people until you have cut your compensation and the compensation of your big-shots.
Define your corporate culture and your principles of management in writing. Don’t delegate this to a committee. Search all the parks in all your cities. You’ll find no statues of committees.
Stop cutting the quality of your products in search of bigger margins. The consumer always notices — and punishes you.
Bear in mind that the consumer is not a moron. She is your wife. Do not insult her intelligence.
I have six of the seven posted. I am not in advertising so I don't relate to that one specifically, the rest however are all great. They seem very relevant in today's tough market, with companies downsizing or looking to penny pinch. At the end of the day, good leaders will inspire others to to success.
Which ones do speak to you the most? Which ones would you add?
Early today I was reading a short blog post over at Scrumology on an age old argument about the fine balance of technical debt and releasing early.
Accumulate too much technical debt and your product's development will slow to a crawl attempting to service all the debt you have burdened yourself with. If you spend too much time keeping yourself debt free, you will miss your opportunity as your product's all important time to market is too slow.
So where do you draw the line?
I think we can draw a lot of parallels with financial world. As the article and its links point out, there is good debt and bad debt. Good debt is debt that builds value (business loan) or the opportunity to build value (student loan) and/or builds happiness (mortgage). Bad debt is debt accumulated to gain things that rapidly decrease in value; they worth less than the debt took on. Think clothes, or that new big screen HDTV.
For technical debt to be good debt you need to gain more then it will cost to retire it.
If you can close a big deal by adding a feature to your product within a really short time line, then it makes sense to do so. You after all have bills to pay, you can get feedback from your customers, and your team will get to celebrate a success and build momentum off of a big win. This can really help morale. (Of course adding features to win deals from specific customers is its own bag of worms, but let's just assume for the sake of argument that this feature is an awesome feature that you were planning on releasing in your next major release, but the customer couldn't wait that long.)
Another example of where technical debt is good debt is in cases where the product/solution is a one off, spending too much time and effort on a clean design is simply wasted effort and not needed. The code will rarely be modified. In these cases you only add to the cost of the product.
And in those cases where the products are not one offs, there is a concept of "luxury design" in my opinion. Especially when considering architectures that need to "scale" or other such "not needed yet" nonsense.
If you are creating a new product to release you don't need to worry too much about "scaling" upfront. Having scaling issues is a "good thing". It means you are successful. It means you have the resources and the business case to go ahead and put the right architecture in place so you can scale to the next level. But putting that in too early and you could miss your market window. You have missed your chance to build value and wealth, and to gain customers.
There are of course cases where you cannot accumulate that debt because the cost is simply too high. For example, adding a new feature to a successful ecommerce website where if the customer experience drops due to performance or bugs you get big a drop in revenues. Here you have the data to prove it that the debt is bad. There is a direct and immediate cost.
Of course with gobs of money and time, you can have the best of both worlds. With a proper user-centered design approach to product creation, your user experience team will be doing user research, and running user tests with mockups and wireframes while your team off building components and backend pieces. It's too bad that this is not more commonplace, users around the world would rejoice.
There is an old adage that nothing in life is certain but death and taxes, and in product development I will advance a new adage for consideration. "Nothing in product development is certain but technical debt and too early release cycles".
What do you think? Should technical debt be kept to an absolute minimum, or is a more pragmatic approach needed?
I have always taken for granted that code with a higher cyclomatic complexity number (CCN) is more bug ridden then code with a lower CCN. This has been taught/assumed for many years. and apparently the old adage about assumptions (ass-u-me) holds to be true again.
I was doing some quick research to find a free tool I could use to measure the CCN of my project as part of its continuous integration environment. This is a best practice of many agile practitioners, and good software engineering to boot. According to this article however, it isn't as useful as it was assumed to be.
What the survey did not show, however, is that code complexity does not correlate directly to defect probability. Enerjy measured complexity via the cyclomatic complexity number (CCN), which is also known as McCabe. It counts the number of paths through a given chunk of code. Even though CCN has limitations (for example, every case statement is treated as equal to a new if-statement), it’s relied on as a solid gauge. What Enerjy found was that routines with CCNs of 1 through 25 did not follow the expected result that greater CCN correlates to greater probability of defects. Rather, it found that for CCNs of 1 through 11, the higher the CCN the lower the bug probability. It was not until CCN reached 25 that defect probability rose sufficiently to be equal that of routines with a CCN of 1.
There is no correlation between CCN and bug counts for code that has a CCN of 1-25! For software engineering wonks, and process improvement gurus this must come as a bit of a shock. So I ask the readers, is the measurement of CCN a sacred cow that should be slaughtered with the rest of those asinine bovine as we move to a more agile and lean software development process? Or is it still a useful tool that should be kept, just interpret the results pragmatically?
It's been a rough 6 months, heck, for many people it has been rough for a lot longer than that. The global economic crisis, economy melting faster then ice cream on a hot July summer day in Ottawa on Bank Street. Admittedly that is not saying much with this summer's unseasonably cool weather.
The fact remains, many people are feeling very uncertain about their jobs, job satisfaction is at an all time low for many people, fear for the safety of their jobs, or the stability of their employer is weighing heavily on many people throughout the country.
With all this doom and gloom what is a leader to do?
There is little a leader can do about the economy, and there is little a leader can do to create job security where there is none, but a great leader can do many little things to reassure his followers, and to bring some light to these difficult times.
Self-motivate A good leader must be able to self-motivate when he is feeling sad, insecure, sick, or tired. This means that you are smiling, positive, and upbeat where ever you can be. This doesn't mean you are to be dishonest, or not genuine, just remind everyone of all the good things that are going on right now. If you cannot motivate yourself to get up, and get going then no one else will be able to.
Celebration time Celebrate all victories, even the small ones. You don't have to throw a lavish party in Las Vegas (though if you do, please invite me), but a thank you card, a small get together after work, or even the a verbal pat on the back can do a lot to motivate people. Rewarding people in an ad-hoc manner with small little things will do wonders for morale, and little to your pocket book.
Invest in people Don't stop investing in people. Don't stop investing in the tools and software your team needs to do their job. In the grand scheme of things, most of these things are "pretty cheap", but mean a lot to those that need them to do their jobs. This will help improve someone's job satisfaction. If you can improve your company's benefit package without busting the bank then go for it.
Communication Keep the lines of communication open. Communicate the good, the bad, and the ugly with everyone in your company. Get up and out of your desk or cubicle. Talk to the people you are leading outside of your day to day job. Talk about the weather (rain), talk about sports, talk about the vacation you just had. Just talk. People will get comfortable with you and may talk about more then just trivial things, perhaps you will learn something that might keep that key player at your company.
These are four simple things that can help improve the morale of those on your team. There are many more small, simple, and yet thoughtful things that can be done to help your team's morale flourish.
What do you look for a leader to do in these tough times?
Agile and distributed development are not supposed to be able to co-exist. Co-located teams are supposed to be one of the key tenants of Scrum.
If you have this (mistaken) belief, then you need to watch this video and presentation. I actually attended this presentation at Agile 2008 in Toronto. If I remember correctly, there were a few skeptics in the room.
The key points are:
Ability to leverage benefits of distributed development
I think the travel between locations is a key aspect of their success, remember that both "sides" of the teams have to be equal. Equal in "power", information, and influence, and treated equally in terms of inconvenience. The "remote" guys shouldn't always be the ones staying at the office late.
Another important point to distributed Agile, or even Agile in general is that practice doesn't make perfect, practice makes habit.
The presentation wraps up with the potentially explosive statement that distributed Scrum has more value then local Scrum. What do you think?
It is getting close to that time of the year again at Macadamian, that's right, review time. Luckily however, it is mid-term reviews instead of the full year end reviews. This time of year always gets me thinking about how we review our employees, and to look around for new ways on how reviews could work.
This year I stumbled across the Cockburn-Boehm Levels of Developer's Competency. The focus of this approach is not measuring performance on generic skills, but rather in terms of how to approach software construction projects. It's not about the skills of developers; rather, it's about the characteristics of the developers.
There are 5 basic levels in the scale, higher is better:
Level 3: Able to revise methods and methodologies to fit unexpected and unprecedented situations.
Level 2: Able to tailor a method to fit a new situation that is expected.
Level 1A: With appropriate training, able to perform discretionary method steps, such as estimating features, tasks, and user stories, complex refactoring, etc. With training, can achieve Level 2.
Level 1B: With training, able to perform simple method steps, like implementing methods, simple refactoring, following coding standards etc. With experience and training could master some Level 1A skills.
Level -1: May or may not have technical skills, but is unwilling and unable to collaborate in a team environment or follow shared processes. You don't want these people on your team.
Then name of the last (and worse) level is illustrative and telling. You would think it should be "Level 0" based on the pattern, but someone is a Level -1 is not a zero, because not only do they not contribute to the team, they actually drag the team down.
Developers at this level decrease the productivity of the team, either through their lack of technical skills, or worse, their poor attitude. A positive, constructive, can do attitude is more important than technical skills. You can usually train people on technical skills; it is much harder to change someone's personality.
It is much easier to be a leader when times are good, when business is plentiful, when the sky seems the limit. The strains put on a leader in bad times are much greater, and this is where you you separate the leadership wheat from the chaff.
A co-worker of mine sent me a newsletter that had a great article on how to lead when times are hard. I hunted around a bit to get the corresponding web page for this article so I could share it. If you are leading people in a company highly recommend that you read this article. If you are not responsible for leading anyone, read this article.
When Macadamian recently had to make some hard decisions, I agonized on how to communicate this to the teams that worked with me. I spent hours thinking about how to effectively communicate the rationale, the plan, and how we can together move forward and succeed. It was the hardest thing I have ever done and I am glad I spent the time to prepare for it.
Is your company experiencing hard times? What are you doing to be an effective leader during this time? What behaviors have you changed?
Pawel Brodzinsk over at Software Project Management wrote a blog about why developers should work on crappy machines. To sum the article up, developers should use crappy machines to force good programming practices on them, and to some extent, good usability. I am sure that most of the reasons behind the post are related to the frustration users feel for having to deal with bloated, slow performing software, or software that doesn't display right on lower end resolutions; and in that, I wholehearted agree.
However, where Pawel and I differ is how we should deal with that. There are two main complaints in the article,
Bloated memory requirements of many applications
Usability of applications on smaller screen resolution sizes
One of my most important missions as a project manager at Macadamian is to make sure that my developers can work as fast as possible. I don't mean to hack out code without regard for technical debt, but that their tools and the processes don't slow them down. Yes process is necessary, but the right amount of process can make the difference between highly motivated, self-organizing teams able to efficiently collaborate between distributed locations, and teams that are swimming in quicksand unable to make a release to save their lives, or their companies.
Their tools need to be top notch, their development machines are dual or quad cores, 4 gigs of RAM, big and fast hard drives, and dual monitors. And yes, some developers still complain about the setup :) We also invest in tools like IncrediBuild to build code faster, and IT infrastructure that can allow you to copy large amounts of data across the network as fast as possible.
I don't want my very talented, and very expensive developers wasting time on waiting for projects to build, new versions to push to production, or code to checkout. If a fresh build takes much more than a 15 minutes to build, you have just lost thirty or more minutes to a game of foozball, a Starbucks run, or a YouTube foray.
So how do you deal with such things like usability, and performance requirements? Simple, engage in formal usability work and create formal requirements on performance that are monitored and enforced by your testing team.
A proper usability team cannot only design UI that can scale to multiple resolutions, but is actually usable by the end user. They can apply actual scientific research to solve usability problems. And you will get the added benefit of having wire frames that your developers will be able to rapidly develop with less iteration and confusion. A picture is worth a thousand words!
This leaves only performance requirements that need to be tackled. Developers can follow requirements (no really they can!), especially when monitored by your testing team. The memory and processor usage, install size, and overall performance characteristics can be defined in the project requirements. The testing team can then apply tools and process to ensure that these are met, and log bugs if they are not.
An excellent testing team takes responsibility for the overall quality of the application, they don't just run test cases. This will mean they will ask questions like "All I did was log into the application and it is using 123 megs of RAM. Why is it so high?". Your testing team does look for memory and other resource leaks as part of their testing don't they?
I agree it is a common misconception that Agile is easy, that Scrum will solve all your problems. That daily scrums and sprints are the path to the rapid delivery of high value software. Many people and organizations say they implement Scrum, but in reality implement "Scrum but". Unfortunately the "but" tends to be the lack of strong engineering practices and a strong Product Owner. Now there is nothing wrong (in theory) with "Scrum but", as a service company, not all of our customers will accept a Scrum methodology, or, we need to follow their development process, some of which are very heavy-weight. But, you need to strive keep the important pieces of Scrum, and the corresponding good engineering principles. While Scrum is a MANAGEMENT methodology, don't forget the engineering part.
In my opinion, the most important pieces of Scrum include:
The daily standup
Strong collaboration tools to share knowledge and keep everyone informed.
Constant communication with the customer (product owner) and the team
Short iterations
Engaged and highly motivated teams
Motivated product owner
In addition to these management principles, some of the strong development processes we use at Macadamian include:
Peer review - all code is peer reviewed by at least one other developer. In addition, the test cases the developer used in his testing are also reviewed by a QA that is on the team.
Daily builds - All builds are run daily, failures are reported to the team immediately. The person who broke the build is severely punished by having to buy donuts.
Continuous integration - Builds are run whenever a developer checks in source code, this aids greatly in the integration and helps catch build regressions.
Automated tests - These tests are run as part of the continuous integration environment, and prior to any patch submission.
Design review - All design is reviewed by the team prior to being implemented. It helps catch any missed requirements and shortcomings in the design. The design can be as simple as some boxes on a whiteboard, or even some interface declarations. No UML is required.
"Wide and Shallow design" - Helps catch fundamental design issues before any of the actual implementation has been done. This allows a more senior developer to help “bootstrap” a project and leave it with a solid foundation for the more junior developers to fill in. Because the design is only stubbed and not cast in stone, the design can still evolve in an emergent fashion.
What do you think? Anything you would add or remove?
Martin Fowler is very well known in the Agile community, in fact he was one of the authors of the Agile Manifesto. Nearly three years ago he wrote about how his company was running Agile companies with teams in Europe, North America, and India. This was quite a few years before most companies were attempting to work on Agile projects distributed globally.
These are all lessons that Macadamian was learning during the same time frame, and I sure wish I had seen this guide to running Agile with offshore development way back in 2006. I read this quite some time ago, but I believe the lessons and practices in contained in this guide should be re-read, and reinforced.
If you are working on distributed Agile practices, or are planning to, read this! Don't learn these lessons through the school of hard knocks. :)
They are pretty classic mistakes, and some of them don't relate at all to Agile. Scope creep, and boring demos are widespread in all companies.
It is important to demonstrate features via use cases, it is something tangible and real. Demonstrating abstract back end technology pieces is exciting for geeks, but not users and they won't be able to easily relate what they see to how it will affect their jobs.
Oh Nevermind! I will just do it myself. It will be much easier, you think to yourself.
How many times have we said this to ourselves, or worse, to someone on our team? How many times have we thought it would be less stressful to just do the task/project ourselves instead of trying to explain the problem to someone else?
Now be honest.
Often? Yeah, me too.
This is a common anti-pattern, especially in the global context when explaining a task with little overlap in time zones. This is where it feels like it will take more time and energy to explain the task then to actually do it yourself. You rationalize this in the name of efficiency. You are being more efficient. Efficiency is good.
Don't fall for this trap! It is an anti-pattern. You cannot be more efficient then a high calibre, well motivated team.
This anti-pattern will have a negative effect on your team's morale as they will see you as a micro-manager. Or worse, they will perceive that you don't trust their abilities. Furthermore, if you don’t take the time to mentor your team members, or provide new and interesting tasks for them to improve their skills on, they will never get better at their jobs, and their morale will suffer. The team will never improve and you will be stuck in a rut.
As a manager your job is to ensure the task is completed as efficiently as possible. Your job as a leader is to look out for their well being, and do what you can to inspire them. A simple rule is to try very hard not do things that will affect your employee's morale; a well motivated and happy employee is a productive employee. A productive employee is an efficient employee. Efficiency is good.
Another part of this anti-pattern is that if you are heads down implementing features, who is leading and managing? Who is looking out past today, or maybe this week? Who is reporting status to the customers, identifying potential risks, building relationships with the customer, or even looking out for the next opportunity? No one is, since you are now focused on the tactical instead of the strategic.
You are creating “project debt” by “doing” instead of leading. Sure it might feel good to make progress on your project, to contribute to the critical path. Maybe get it out the door sooner, perform some technical kungfu. However, you are incurring a lot of “project debt” to do this. At some point “project debt” comes due, and it might be paid for with a missed opportunity, or an unhappy customer due to a mismanaged relationship.
So we recognize that this is an anti-pattern, how do we assign and explain tasks efficiently?
In a push task management model, assign tasks several days in advance, and instill a mindset that the team reviews their tasks as soon as they are assigned, even if they don’t plan on starting the task right away. This will allow the team to look at their tasks and seek clarification or answers ahead of time, before they are actually trying to perform the task. Sometimes their questions will flush out missing requirements that might need to be thought about with the customer or product owner as well.
The same thing applies in a pull task management model, encourage your team to pull the tasks ahead of time, so they can ask any questions they may have before they are blocked for a day waiting for you to answer their questions, or in some cases, wake up.
Explain the tasks in person, or over video/voice. Follow up with a written explanation. Email works, but a wiki is better. There will be more transparency to the rest of the team, and it will be easy to keep the wiki up to date when things change. We all know things will change right :)
After you explained the task in person, ask questions to make sure they understand, especially around requirements and any time sensitive pieces.
In some projects, we use a concept of a “design patch”, in it the developer explains their development approach, basically how they will implement the feature, and how long they think it will take. This isn’t to micro-manage, but often will highlight any lack of understanding. It also has the benefit of improving the teams planning skills and ability to do top down design.
Those are five quick ideas I have, how do you delegate tasks?
Have you ever met someone who blurted out random technologies or methodologies, at seemly random and inappropriate times? And furthermore, it seems like they are talking out of their you know what? If you are anything like me, then you have had the misfortune of having to cope with this.
Technological Dysentery Disorder (TDD) can afflict many people, from project managers, to sales, to executives, customers, developers, or even in rare cases, QA. Unfortunately, there is no cure for this disease, but simple coping strategies can help mitigate and alleviate the symptoms. It is especially serious when it affects QA, as a QA’s role often dictates that they bring sanity to the projects, and keep the rest of the team in line. When TDD strikes the QA, this is a worst case scenario, just like when illness strikes frontline healthcare workers.
One of the best coping mechanisms is to understand why the flare-ups are occurring. The two main causes of TDD are:
A desire to appear intelligent in front of peers, subordinates, and/or vendors
A strong fascination with technology, a fascination that is so strong that every single problem looks like a nail that needs to be bashed with the mighty hammer of technology
Understanding the underlying reasons for these outbursts will be very useful in helping you keep your patience when dealing with those afflicted.
Another important coping strategy is to refrain from engaging in debates or arguments about technologies or methodologies except when absolutely necessary. Engaging in debates on technology in sales or standup/status meetings is not ideal, you will end up going off on a tangent and wasting everyone’s time. Instead, focus on solving the underlying problem instead of focusing on the technology.
When you are dealing with a stakeholder who is suffering from TDD, try to guide the discussions away from technological, framework, or other non-important issue, focus on the problem, not the technology with which to solve it.
At the end of the day, an expert is a problem solver, not a technology implementer.
I had an AH-HA moment when Francis mentioned that "Agile is not a process, it's a mitigation strategy". Truer words have never been spoken.
If you are interested in more about what Alan Cooper thinks about design and Agile, catch his keynote address at Agile 2008, it was very controversial.
This is his complete slide deck and his speaking notes, sorry, no audio. If you want to listen to the audio, one of the attenders of the conference taped it.
The most recent edition of the edition of the Agile Journal has a neat little comic talking about how you calculate the last responsible moment.
As I was reading through this comic I came to a realization, it is what the military would call a time appreciation. You start with when you need the task to be done by and work backwards. It is a pretty simple exercise in logical analysis and problem solving.
It's an old joke to ask if the dog wags the tail, or the tail wags the dog. The saying fits in many contexts outside of media, including the age old battle between testing and engineering, or the usability of the application, and the technical design of the application. Do the user experience (UX) folks design without regards to the technical feasibility of their work, or does the engineering team dictate design by imposing technical constraints?
Jumping in the way back machine, five or six years ago I was working on a large web application, it was Macadamian's first project where the engineering team implemented the output of an interaction designer. When asked, I told the designer to go ahead, don't let technology limit your designs. Sure enough, we ended up creating an impressive web application (see left) with all the bells and whistles of a rich internet application, all back in 2003. I also lived at work for weeks implementing all that cool stuff. I wish I had read this article back then!
At Macadamian, we have had a world class user experience group in-house for the past few years. Learning to work with this new UX group was not an easy task for a primarily engineering and quality assurance company. It took more then a couple of months to work out the process for collaboration between UX and engineering. Everything Tim has discussed we have also learned, the hard way.
Being that I come from the engineering side of Macadamian, and that most of the costs of the project are on the engineering side of the project, the point that jumped out at me the most was the suggestion to listen to the concerns of the developers.
The first few combined projects between the engineering and UX group resulted in significant schedule delays and cost overruns on the engineering side due to really good, really cutting edge, and extremely difficult to implement designs coming out the UX group. When the estimates were created, the estimator put time in to basically add some form fields, text, and maybe a graphic or two. Pretty naive.
Unfortunately (or fortunately depending on your perspective), the customer saw these designs, loved them, and then expected to get them for the same price as that form with 23 checkboxes and 97 form fields. The complexity and innovation required on the UX side was not expected on the fixed-bid engineering side.
To solve this problem, a simple (and in hindsight, obvious) process improvement was made. The developers had a chance to look over the designs prior to the customer seeing them. This allowed any potential design decisions that would adversely impact the schedule and cost to be caught, and fully discussed prior to the designs being approved by the customer. It wasn't that engineering had a veto over the design, it was allowing the usability group to be made aware of any potential technology challenges to be discussed earlier in the cycle.
This allowed the two groups to work closely together and solve any potential issues. Sometimes the UX folks were able to convince the developers of the critical nature of the particular design, and other times the user experience group came up with another solution that was just as usable, but much easier to implement. However, don't confuse this approach with one where technology drives what personas can and cannot do with the product, that would be a mistake. User needs have to drive the design.
No matter what some people might say, faking it is perfectly acceptable. Seriously, faking it allows you to get finished your task sooner. Some people think that faking is cheating, but it's not.
Ok, enough with the double entendres, what am I really talking about? Why using mock objects or stubs of course.
Stubs are more common in the types of projects that we tend to do, but we do use mocks as well. I really like these design patterns and try to use them often to decouple different teams from each other. This being said, the concept of stubbing and mocking is starting to become a bit of a lost art.
Once the interface and supporting data structures are designed, one team can start to work on developing the user interface using stubs and mocks whilst the back end team works on implementing the actual functionality.
This has several benefits:
It removes the back end team from the critical path
Facilitates the creation and maintenance of unit tests
Facilitates the top-down coding methodology
Provides an actual user of the APIs and data structures to validate their design
Allows the team to focus on the big technical risks
Helps facilitate the separation of teams
Shortening of the Critical Path By the smart application of mocks and stubs, the manager can reduce the overall critical path of the project and the dependencies on the back end team. All the teams need to collaborate together to define the interfaces and use cases, but once that is done the teams can work independently, and most importantly, in parallel. Without the use of stubs and mocks, the user interface team for example, would be unable to accomplish much work until the back end was implemented.
Creation and Maintenance of Unit Tests Many teams and projects now work in the Test Driven Development methodology, or at the very least rely on unit tests to demonstrate correctness of the code and help guard against regressions. The use of mocks and stubs can help encourage the creation and maintenance of unit tests by allowing the developers to first stub the back end and then write the unit tests to exercise the interfaces. Additionally, mocks provide the ability for the unit test writer to write the unit tests that exercise code that relies on complex objects. Additionally, since mock objects implement the interface and simulate more complex real objects they allow programmers to implement and unit-test features in one part of the application without actually having to call the more complex underlying objects. A broad, well maintained unit test suite will give you the manager a lot of confidence with regards to the overall quality of the application. In addition, a good test suite can give the manager a lot of confidence to approve the re-factoring exercise without fear of introducing regressions.
Facilitates top-down coding Stubbing and mock objects are an essential part of the top-down coding methodology, or as some people like to call it "breadth-first coding". Read the link for a much more detailed explanation then what I have room here for.
Validation of APIs and Data structures Often "paper" doesn't match reality, and the best designs on paper fall apart in real life applications. The use of mocks and stubs that meet the interface requirements and behaviors of the design allow the users of the interfaces and complex objects to actually use them in a real life scenario while the real implementations are still progressing. This can safe costly redesign and re-factoring exercises, both in terms of budget and schedule.
Move the big rocks first Clever use of stubs and mocks allows the team to focus on solving the big technical hurdles without getting bogged down in the small little details of the project, the so called while stubbing "boilerplate" functionality. For example, your web application needs to implement complex domain specific functionality that requires a lot of collaboration between the development teams and the stakeholders, of course you need user management and login, but those problems have been solved a thousand times before, and the amount of work required to implement them is well known, leave the actual implementation to the end. Removing the technical hurdles upfront in the project allows the manager to more accurately estimate the end date of the project as the most riskiest items in terms of budget and schedule have been solved.
Separation of teams With today's global teams distributed across the globe all efforts have to be made to decouple the teams and reduce time to market while at the same time keeping the project as a whole cohesive and highly productive. When the developers from your user interface team come to you and say they are blocked because they are waiting for the back end guys to finish their service layer, or that no one but the team here in the head office can work on that feature because it depends on another feature from another team, remind them of the concept of stubbing the APIs and mocking the complex pieces in the interim, this may well indeed allow another team in another location work on that feature with little to no impact in quality or time to market. Of course the teams still need to communicate constantly with each other. The ability to easily separate areas of the application will help the manager build out the team in multiple locations, potentially allowing the team to grow faster then could be hired locally.
As a manager at Macadamian I am often asked my opinion on many subjects, from straight project management, to leadership and people management, to personal matters of some of the people that work with me. Jason's blog post makes some great points on how to recognize great constructive criticism, so it only makes sense that take some of those points and apply them when giving advice or constructive criticism.
I agree that often people seeking advice know what they need to do, they just don't necessarily know that they know, and asking pointed questions can often guide the person to the answer they are looking for.
Oh, and I will try to never ever say "because that's they way it was always done".
This looks like a really cool toy, not quite as cool as a parental version that allows a parent to put the headset on a direct the child to clean their room!
Not many people understand how the average developer spends their time while creating web content. If you haven't done large scale web development, you just don't get it. Hopefully the graph below will help explain how their time breaks down, and maybe help move them up the totem pole.