Sprint: plan just enough, do it, reflect

“Sprint” – what does it mean?

Note: my definition of sprint is not by the book. It’s perfectly fine by me as I love adjusting theory to practice; I hope it is okay with you as well. Basically, a sprint is just a time window that you plan to achieve something at. Just imagine a box with your interesting “todo” notes. For example, in the next 2 weeks you may want to plan to perform some proof of concept for your initiative; plan to create 3 landing pages to check which one covert users better to registered users; plan to write a tutorial or even plan to upgrade your team’s computers.  

Why do I need to define a specific time window then?

The idea of a sprint, in essence, is simply to (1) ease psychological acceptance of changes and (2) allow shorter, just-in-time planning.

Specific time window, made constant (sprint after sprint), allows you to understand that things might change and you now made mental and physical “room” to adjust when needed. It’s a bit of sugarcoating, of course, but it’s making the transition smoother.

The just-in-time planning part is more “acceptable” when you’re embracing the fact that it’s too damn expensive trying to break all effort into small pieces. You’re customers are “allowed” to change their mind, so – what’s the point of understanding that something being requested for next year, will take 121 hours to develop? In 2 weeks, hell, in 2 days, this effort might cancelled. Breaking future effort to small pieces is great, but only if it’s extremely cheap to achieve or extremely relevant now. Until then, you might be okay with high level estimation.

The perfect size: big enough, small enough

Sprint should be big enough to (1) achieve meaningful progress and (2) avoid unacceptable overhead of planning + reflection. That means that if your smallest effort is always at least 1.5 weeks, don’t use 1 week sprint. If you need a full day to plan a sprint and another to reflect on how it went, don’t use 1 week sprint. Otherwise, your people might feel “we’re doing nothing but planning and reflecting”.

Sprint should also be small enough to allow to reflect and adjust often. Just like “release often” attitude, adjust often will make the organization work better, faster. Don’t dismiss it lightly.

How many sprints should I plan in details?

Good question if I may compliment myself for asking so. I would aim for detailed plan at least 1-1.5 months in advanced, unless you’re in a really volatile market and 1 month is “too far”. If your sprint size is 2 weeks, then I would say around 2-3 sprints. By saying “in details” I mean very detailed understanding of effort, real breakdown or very solid understanding, based on similar effort in the past or one-of-a-kind magic ball. The idea is to have good image of near future; this will obviously be expensive to create, but will give you confidence on how to achieve the most important goals on your table.

I would try to understand what’s coming later on (3-6 months), but invest much less time and stay with high level estimation. I don’t want to waste time on planning potentially irrelevant effort.

Natural dependencies planning

When sprint size picked wisely, there is much “smoother” feeling of dependencies planning. There is no real need for Gantt or something of that sort, thank God. Everyone will be aware of the effort being made in the sprint and will align dependencies accordingly. The feeling will be more natural, more just-in-time rather the stating “we need infrastructure team to finish in 6 months something so we could use it 9 months from now!”. It doesn’t mean that dependencies planning is gone out the window, you’ll still need to do so for big infrastructure effort, but you’ll see that it happens less than you were used to. This is a good thing.

Reflect and adjust

At the end of the sprint, it’s a great time to sit down and consider what went well, what wasn’t (take Action Items) and what can be done to have better sprint next time. You’ll adjust to external changes better when you’ll adjust to internal pains better.

I thought that Agile == no planning

Now, that is just sick. Seriously, no one is expecting you to work badly. Great planning is the only way to produce great products to your customers, deliver it on time and with high quality.

Not all planning are born equal

Accept it, plan accordingly :)

 

Left Brain Storming

We’re doing a lot of thinking these days about which features will give us the best ROI, trying to prioritize existing features and asking ourselves “did we miss something? is there a new feature out there we left behind?”. It’s not easy to think about great one-of-a-kind ideas. It is easy though to make it almost impossible.

Why? it’s all because the “parallel” right hemisphere of our brain, imagine the following brain storming conversation:

me(Left brain): Alright I’ve got one! The user will enter the screen, do X and Y (we’ll do some Z behind the scene) to receive …
   me(Right brain kicks in): but, doing Z will take me two weeks to develop..
   me(R): gosh, we’ll need to build a dictionary and hold it in memory if we want it to scale..
   me(R): reminder, use ReaderWriteLockSlim this time. It’s much faster than ReaderWriterLock!
   me(R): I guess that this feature is not as important as feature F1, maybe I’m spending my time thinking about this feature??!
   me(R): I’m so hungry!
   me(R): Oh, we can use [some service name] to do Z. Cool, so now this feature is feasible.
   me(R): crap, [some service name] cost money, I think.

[To the surrounding, it looks like I’m saying one fluent sentence of course. During that time they have their right brain working on “why not” / “how” / “when”]
 
   joe(R): gosh, is he for real? this is the lamest idea I’ve heard!
   jack(R): hmm, maybe he have a point there. This feature reminds me something I’ve always wanted to do… what was it now??…
   jack(R): naa.. this guy is crazy. for sure.
   joe(R): oh wait! we can use something I wrote to implement this feature! might be cool to use this code finally. It is laying there for ages.
   sarah(R): wonderful idea! I wonder if I’ll be assigned to work on it?
   jack(R): I’m listening to his bubbling for 20 minutes now. self reminder: talk about a bonus with the CEO.
   sarah(R): I need coffee! God, if you’ll end this meeting now I promise the donate 10$ for charity! coffee… please…

me(L): .. a brilliant search result !!

Any wonder that most brain storming meetings are futile?

Brain storming is a process that should be mastered and I suggest that you’ll jump to the nearest browser to find books at the topic, it’s a skill worth investing time at.
Before you do so, here are some rules I use to silent my right brain while doing Left Brain Storming:

  1. Never ever prioritize your ideas during brain storming. I can’t stress enough how important is this rule. Don’t worry about it now, you’ll have time later. 
  2. Listen to others.
  3. Be patient = don’t judge quality of ideas.
  4. Write everything down. I really mean everything! There are no “stupid ideas” now.
  5. You are not going to execute these ideas. At least that is what you should tell your right brain during that time.
  6. Understand the meaning behind the feature, imagine how it will work, not how it will be executed!
  7. Don’t invest more than 2 hours in a single brain storming meeting. If you feel you’ve missed some ideas, rest a few hours (or even better – a few days) and then give it another shoot. “Burned out quickly, left brain does. Burned out leads to impatience. Impatience kicking the right brain in action. Right brain means trouble for your brain storming meeting” — so does Master Yoda say (well, sort of)
  8. 80/20: after you’re done throwing out ideas (or the 2h gong), go over the features you’ve raised and mark features you think are interesting and feasible with 80 and features that are not with 20. This should take no longer than 2 minutes, so please use only 80 and 20 as numbers.
  9. Set a separate meeting to prioritize features with the existing backlog you’ve got. Important: don’t do it at the same day, you’ll probably want to sleep things over.

Happy hunting!

 

No, THAT is not Agile

Let me start with an out-loud recap of this post: Agile is not something you can put on a bread nor is it “a certain path to success”.


It’s about STATE OF MIND.


If I had to describe the meaning of “Agile” to a new teammate I would say: Agile is a constant thinking about how we, AS A TEAM, can produce working features to our users with high quality within a short time-frame.

Don’t worry:
It’s really OK to provide only a subset of feature(s) in one sprint.
It’s really OK to leave SOME designing\architecture issues for later on as long as the high-level architecture is good enough (=you’re comfortable with it) to answer the big questions.
It’s really OK to implement only two REALLY-DONE-HIGH-QUALITY features in one sprint over four semi-working-not-demoable features.


The key here though is not really the practices, it’s about the big bullets(again, state of mind):


1). Produce value for your customers and adjust\adopt early.
2). Build a Team (self leadership).


These ideas are hard to implement and require special kind of people. Putting the Team in front of yourself is not a very job-secure attitude.  The ability to help your teammates, shift tasks, taking ownership, critisize yourself and your teammates and getting better, produce high quality design, tests and code – all of it – requires versatile people with unique state of mind (and unique abilities, of course). It’s worth it. When things glue, it’s a real magic; Things start to get going by the Team, improvements and features starting to come from the developers\QA\Graphic Designer, adjustments are made on a regular basis, changes are welcome and productivity is celebrated.


You can feel something is going right.
That’s Agile.

 

Continuous Integration as Quality Reflection

One of the most common question in moving towards Agile Development is Where should I start from?. If you’ll ask me, setup a Continuous Integration (aka “CC”) would be the first thing you should start with.


Step 1 (Check for compilation bugs): Code Quality ~= 30%


The CC should be able to identify check-ins to your source control, get the latest source and compile it. The output should be either “green” (Everything compiles successfully with 0 warnings) or “red” (more than one warning or compilation errors). In addition to the fast feedback, the output should also include the files that were changed from the last build (and by whom, so people could know where to look).


The immediate value is priceless. the ability to SEE whether your source-code is stable enough to allow other programmers perform Get Latest and continue their work and the “fail-fast” attitude can save you a lot of time in the long run. It’s important to realize though that even if the code compiles without warnings, it still doesn’t mean that you could count on the quality of the code.


Step 2 (Check for component-based quality): Code Quality ~= 70%


If you can go one extra mile, write a few automated tests (via one of the available XUnit frameworks) for your components. This means that you are able to inject the component’s dependencies from the outside and simulate mini use-cases on component’s level. This step is crucial even if you write those after the code itself was written. Let the CC run them if Step 1 is OK. This should allow you to catch the majority of your bugs (I’ll leave the “how to write good tests” to another post). If all is green, you know that the system behaves as expected, at least to some extent.


This step is not trivial as it requires you to design for testability and invest in proper testing. Don’t let go of this step though, automated tests on this level will make your life much easier. It will take your code one (major) step ahead in “write code that could be changed”. Agile is all about that state of mind.


Step 3 (Check for integration-based quality): Code Quality ~= 80%



Now that you’re components are behaving as expected, you should try to write a few (automated, of course) tests that simulate the entire flow of 2 or more components (DB is a component as well) in the system. As the system grows and more uses cases are added, you should try to improve these tests as they give a solid proof that the SYSTEM works.


Step 4 (Make everything visible): Code Quality ~= 90%


The state & quality of your source control should be visible to the Team and Management as you want to insure IMMEDIATE response time in case someone check-ins a low quality code (on any level). Fixing a failing test three days after the change itself is a bad symptom of low visibility or low perception, by the Team, regarding the importance of the quality of the system.


Step 5 (Automated deployment): Code Quality ~= 95%


After successful build you would like to deploy the latest source on a dedicated environment which the developers could play with before deploying to another (testing?) environment. This won’t be a stable environment, but at least it will give a quick look at the current state of the system – the way customers would see it.


Step 6 (Procedures checking): Code Quality > 95%:


You can add many more checks to the flow, such as Tests Coverage or FxCop. Leave those to the end. From my experience, Time .vs. Value in these features will vary from team to team. You’ll gain much more from investing in Steps 2-3.


 


Semingo CC:


Each developer & manager on our team have a CCTray(the little red circle in the little picture above) which is either Red(source control is damaged), Yellow(Build in action) or Green(Life is sweet). We’re using Cruise Control.Net, CCTray, MSBuild (and TFS plugin) and NUnit to perform all of the above. 


A few teasers:


* Image of Steve Urkel (from the famous Family Matters TV series) is shown for failing build.


* On the right you can find Pasha (with a V sign I’ve added), one of our finest hackers modeling a successful build. You can also notice the 582 green tests (including Integration tests) and 2 changes made by Sagie since the last build.


* Going to NUnit Details, you can get the full details:


 


I had to cut the pictures in order to keep a sane width for the post, but you can get the drift.


btw – Aviel, yet another Semingo hacker add a “Doh!” (Simpson) each time the CC is red on his computer. It can be quite funny (and scary, if fully concentrated on code).

 

Semicrum – Implementing Scrum at Semingo

After almost 1.5 months of Scrum at Semingo (a baby startup), I decided to expose the way we work at the moment and talk about the adjustments we’ve made in order to suit Scrum to our needs.


I’ll start with our implementation to the Daily Stand-up Meeting. No doubt, our meetings are pretty funny (most of the time) and create the right vibe for the Team. The one thing I love most about our meetings is that by the end of the meeting, I know what is the general work-plan for each member in my Team.

Now it’s easy to know what I’m planning to complete today (I spend 5-10 minutes planning my day before the meeting), when & if I need to finish something earlier (or at least decide about interfaces after the meeting) in order to integrate with others, help out or ask for someone’s else help(code review for example), stay after the meeting in order to talk about something that pop up during the meeting, remove impediments (if I can) and most importantly – have a good laugh before the day begins.


Daily Stand-up Meeting (aka DSM) structure at Semingo:


When: 
Every day at 10:30.
Where:
Meetings room.
Time Box:
15 minutes.
Attendants: 
Pigs only (Chickens can (only) listen)
On the table: 
Each Pig answer these 4(!) questions:
(1) What have I done since the last DSM ?
(2) What am I planning to do until the next DSM ?
(3) Impediments – what bothers me to work ?
(4) Am I on track?
     If someone feels that one of his tasks won’t be finished as planned, a flag is raised so the Team could assist. 
     The same goes if someone feels that he’s going to finish before the expected time. 
     This means that he could help out someone else or take a few extra tasks we did not plan for the current iteration.

Notes:
Only one Pig talks at a time and he leads the conversation if reasonable questions comes up. He (alone) has the power to stop a conversation if he feels the conversation stray from the DSM path. Team members can decide to talk about an issue that was raised during the DSM just after the meeting is finished.


What next (DSM planned improvements)?
(1) You late, you get (punished, that is): each team member that late to the DSM must wear the “I was late to DSM, I will serve you coffee today” sign on his shirt.
(2) Red-Back on track: If the conversation is getting out of control (too many jokes, drill-down conversations, more than 1 Pig talk etc) – the red button is clicked and each Team member is being electrified with 120V. Well no, but it could have been a nice feature right? Clicking the red button will make a nice GONG!! so we could move on. The Team agree to listen to the GONG and get back on track, so we could finish in time and keeping the DSM productive.

 

Transforming into a Team

One of the principles behind Agile Team, is the commitment of the Team to finish the planned features for a given iteration. There are times when some members in your team will finish their tasks early while others will stuck on unplanned or underestimated tasks. In a perfect world, each one of your teammates would be able to perform any kind of work whether it’s design, writing database queries\commands, program, create graphic interface, test. At least to some degree. On the Agile community, these kind of people are called “generalist specialist”. This will allow the Team to help each other and keep their commitment. In most of these scenarios, the teammates will help each other as a natural process of feeling as one unit. But things are more complex.


The problem is that you still want to hire a great SEO specialist, a great web designer or a great DBA, so this leaves you with the question “how could they help the Team meet its commitment?”. We can’t ask a SEO specialist to write multi-threaded C# code, which leaves us with a Team and a bunch of consultants that try to aid the Team hold to its commitment. I’ve seen this behavior of “consultants” inside teams leading to the notion of “Look, I’ve actually finished my tasks successfully! it was the Team that failed…”.


Could we really try to use our SEO guy for multi-threading tasks? most probably not. The trick here is to find a common ground so we can bound our SEO guy into several fields, making him feel as part of the Team. For example, the SEO guy can make some web design by helping to create a SEO-correct HTML (thus helping to take some pressure off from the web designer) or maybe helping the architect design the user interface. One of the things we’re doing now at our Team, is introducing our beloved DBA(Shlomo – I’m waiting for your blog dude) into writing the data-access layer in C#. We’re doing it step by step, while I’m trying to explain about working methodologies and doing some pair programming. It will take us time (baby steps), but we’ll get there.


This change in state of mind is not easy, but it is crucial if you want to jell your teammates into one Agile Team. Notice that I’m writing “Team” rather than “team”. I see Team as a single entity, a solid force driven to hold to its commitment no matter what (while still keeping high quality delivery, of course); This is very different from a team, driven to do as much as it can, each one on its own, without being responsible for the greater good.


Being a part of something bigger is a motivation boost you shouldn’t underestimate. For me, there is no bigger satisfaction than taking ownership over an entire application (instead of “I’ve fixed problems 1 and 2 in product A and problem 5 in product B”), working hard and making it work at the end of the day. Doing that, you could honestly say “I’m responsible for the success of our product, and I’m damn proud of it!”.

 

What is Agile all about, really?

Agile is really about forming 1-BIG-happy family or in geek terms: one collaborative unit of work.


If you go over most(if not all) of the practices Scrum\Agile\XP have to offer, you’ll find two things in common: how to make your customers ROI as higher as possible as soon as possible and bonding everyone together so they are ALL responsible for the ship to move forward, one step at a time, constantly. Good-will and high IQ is a (really)great start but never enough. At the end of the day, customers understand working functionality described in user stories(“I will be able to move my money between my bank accounts”) rather than functional stories(“The system will supply Web Services in order to integrate with our billing system”) and most importantly – they’ll only pay for the former. But the technologist part in me(I’m made of 70% water, 29% 0 and 1, leaving about 1% for adult context), understands that we programmers really love to solve hard problems in elegant ways. I never saw nor hear a developer jumps up and down saying something like “I made it possible to move money from account A to account B!” or “The user can now get his lost password via email!”. I just love the idea of creating a successful setup so our brilliant guys will be able to transform their IQ into business value. What a noble idea, actually making one’s talent into a fat paycheck (I’m probably the only one finding it romantic am I?). 


In many ways, gather the “right” practices for the team is like getting ready for a lecture in front of a big (important)audience. Forming a good lecture requires a lot of thinking(what do I want to deliver), preparation(how can I do it), ice-breakers\funny stories(keeping them smiling  and cooperative in the process), motivation points(keep their eyes on the ball), examples(proves that it works) and most importantly – letting your audience know what they’ll gain from this lecture(high ROI) and keeping your promise. Don’t be a fool, trying to enforce the process or make a shortcut will be like participating in a lecture where the presenter decide to write a set of articles in his slides causing you to look at the 100–inch-screen-with-1500–words-per-slide, thinking it will deliver all the data you’ll need. It never does.


How can you start making a change(including improve an already great practices)?



  • Read, listen, view, try things, write notes. Play the secret agent role and try to learn your enemy.
  • Let your people know about these practices. Open their eyes into new ideas.
  • Explain how things will work from now on, how it will look in 2 months, 6 months, 1 year, 2 years from now. Inspire them.
  • Answer their questions, make them trust in the system and trust the family.
  • Detect negative workers and detach them from the team. NOW.

A little push to get you going:


 

Vision from an ex-software prisoner, Part 1

Too many times in our lives as developers, we feel that in spite of our talent, skills and knowledge we just can’t seem to bootstrap ourselves from the mess we’re in. It reminds me many movies (and the great Prison Break television series) where you see a nice, innocent guy put into jail with a bunch of murderers and rapists. After stabbing a guy in order to prevent from being stabbed, our hero gets into more trouble than he started with. This vicious circle goes on and on so by the end of the movie, you are not sure what he could have done different. His skills, talents and knowledge were thrown away, replaced by the need to survive. In many scenarios in life, I feel like that guy.


Avoiding the (really)poor analogy of un-unit-tested\unmanageable\coupled\you-name-it software to jail, I decided to stand up to the challenge(talk about “What not to do”) raised by my friend, Uri Kalish, and share with you my vision regarding top mistakes I have experienced in the last few years. If it will able 1-N (see, I just had to be all geeky about it, even after talking for a full paragraph on jail and murderers) of you guys & gals to change 1-Z things in your world, this post will worth any future creepy comments I’ll get from real ex-prisoners (what?! there must be some ex-prisoners .Net, Java frustrated coders out there, right?).



  • “Promoting” best coders into solely management positions
    It is the fear of losing someone and the way our community treat one’s status causing this behavior. To make things worse, in most of these scenarios, the company (somehow)feels obliged to let him\her* manage 4-5 people so there is no fat chance he’ll write code in the coming 2-3 years. I believe that this is the top-1 fatal mistake companies do. They are losing their most talented, most efficient programmers without the right adjustment and natural growth by the rest of the team. The way I see it, this is what a Team Leader should be responsible for:

    • Code for at least 60% of his time. Not 20%, not 30% and most definitely not 50%(this will cause him to fall back into 60%-40% manager). Great war leaders were great warriors, always on the front of their men. If you prefer to be left behind(technology speaking), managing from above, you should not be a Team Lead.
    • Get to know your people – what do they like to do after work hours, what are their hobbies, write down their birth-dates so you could buy them something symbolic. Make them feel like home. Spending 10+ hours in the office is more than most of us spend in our home. Notice how a very cheap gesture may change your team’s world – some people like fancy keyboards, some(I’m included) prefer a big LCD screen and others prefer an extra bonus. Let’s say that you invest up to 500$ per person, the ROI is still tremendous(try to think your hourly cost and how fast you’ll return it). People will have everything they need(=want) in their office. Google is famous of hiring the best just because of taking care of the small details.
    • Manage your team’s time – help to set the deadlines per sprint\iteration, but more important – analyze the team’s productivity by picking up time estimations and actual time spent, and perform some calculation via various tools to understand the bottlenecks your team experience. Make them see, make them witness of how they can become more productive with the right set of exercises.
    • Be a mentor by leading the team with daily improvements. Change the way they think, blow their mind with new stuff. Direct them to “home reading” that you know they’ll enjoy. Make them excited! Be a great developer for them.
    • Shield your team members from political business. Make sure no one is interrupting them meeting the deadline.
    • Meet the deadlines. Don’t afraid to speak your mind when things are out of track. Make them see you’ve got what it takes to lead them back to the right path. Tough love may create great developers with the right amount of genuine caring.

         This will allow the Team Leader to remain an efficient programmer and the team grow into the new situation.         
 



  • Big teams
    Team size should never be more than 4, where preferable(IMHO) is 3. We want our Team leaders to write code, remember? Managing more than 2 people other than yourself will make your TL too busy to code. Even worse, big teams will cause team illness:

    • No matter of how much good-will exists in the team, keeping many people in the loop is simply too much overhead. It will wear off your teammates.
    • This will divide the team into smaller “virtual” teams, each one is built around a user story or a complete feature.
    • Now it’s getting hard to know when you’re breaking things for others as no one is really into your teammates code or requirements.
    • This leads us to the most unwanted behavior – no one in these virtual teams is an expert on their domain as the team switch context all the time to meet the big team deadlines. Context switch and lack of domain experts will kill you team. From inside out.

         Keep your teams small. Managers should sync the small teams and keep the eye on the ball for them. This is their skill, their talent.



  • Waste valuable time on the wrong tasks – skills .vs. tasks impediment
    This one really gets me. How many times you’ve been asked to do something you know you shouldn’t have assigned for? Giving a c++ hardcore hacker to write HTML is silly(at best). Now, I can relate to the feeling managers have assigning these tasks  just to keep the deadlines but this shows of lack of creativity rather than good leadership. For example, the c++ hacker will cost around ~X5 then a young talented designer (by young I mean 16 years old cool dude that’s doing it from age 11). Hire someone, even for a few hours a month and let the them do their magic. From some reason, managers never thought about hiring a graphic designer to write hardcore c++ code, right? It will be amazing to measure the ROI you can show your bosses even after 2-3 iterations just by putting the right players in the right positions. The same goes about database, system administrator, (customer)documentations etc. Stop treating someone’s time as equal to someones else time. hardcore multi-threading guru will not enjoy a full day or two of playing with HTML to fit different resolutions. Be creative and make the adjustments! 


I have a lot more rants and tips but I’ll leave it for further posts so be good and stay out of software jail.







[*] – I’m sorry but writing him\her all over the place is plain crazy. You know I’m no sexist ;-)

 

agile Confidence

Wow, it’s an Agile world we’re living in isn’t it ?


Could you guess how many hits you will get by searching “Good Agile” in google? about 12 million!! “Being Agile”, “Agile principles”, “Agile stories”, “Agile practices”, “Good Agile, “Bad Agile” – millions of books and articles out there for us to reach. Buzzwords addicted as we are, we try it all. We pair programming, we work in short iterations, we drop features early and receive early feedbacks, we combine our developers with our QA guys to create some sort of “Feature Team”, we use cards, backlogs, big boards with colors, we Scrum, we XP. We practice. We succeed. We fail. We try. Still, a lot of people all over the world claim that Agile Development don’t actually work and those methods cause more damage than good. Reading Stevey’s post about Good Agile .vs. Bad Agile made me think about my definition for successful agile development. 


Do you ever seen StarGate? if not, it’s really not too late to buy a DVD and catch up. In this great TV series, SG-1, the “main” team on StarGate, explore the galaxy through a series of Star-Gates, each one located on a different world, which allow them to move from one gate to another through some sort of wormholes that connect the gates together. Their job is to interact with other species, to establish alliances and to acquire new technologies. SG-1 is my definition for an agile team.


Let me introduce you to the team:


jack.jpg


Jack. A confident soldier and the ultimate manager – he will be the first one to take to bullet, always believing in his teammates and letting them do their job with full confidence. Improvise is his nature. His team are his family. He’s the one that make the team glue together.


sam.jpg


Sam. The genius scientist of the bunch. Do you need someone that will write your Java paper for the university in alien dialect? Do you need to make your car a flying ship from two gums and a rope? Rummer has it that she wrote Skype in pure assembly just for the fun in it and that WCF was actually planned by her(Juval Lowey disagree, though). Never says no (I am naughty…) and always do her job in a professional matter, thinking two(thousands) steps ahead(the 100000 alien she killed concur).


daniel.jpg


Daniel. “I can talk 10293740447303^2 languages in 2827349*3 different dialects” guy. If you have a beloved dead uncle whom you’re dying to talk with, page Daniel and he make it happen. Got a book from 1700BC in Chinese that you are really eager to read, he’ll translate it into English in an hour. A passionate guy that manage to calm the team under fire an to make some sense of Jack’s nonsense.


tealc.jpg


Teal’c. The muscles. Teal’c is an alien that joined the team after being slaved to the “gods”(high rank politician with some impressive gun power) in his home-world. He can kill a nation and shave simultaneously. Brave warrior that brings the confidence the team requires during hard times. If you are an AC Milan fan as I am, he is kind of Gatuso – you thank the lord that he’s on your team.



You know why SG-1 is the ultimate agile team? because of the people in it and the way the complete each other. See, you can learn the tactics, get the right tools but without the right men in the right position, you are as good as dead. From my experience, there are bunch of actions you can do to make your development process as agile as possible:



  • Invest time in developing inner tools for your workers. You need tools to help you code(good IDE), to control your source, to set up a Continues Integration environment, to perform Daily Builds, automatic Unit Testing and Code Coverage, to run automatic UI and Sanity tests. You will want to easily create setup files and deploy them on various testing environments all in a single click. You want fast feedback that your product is stable each and every day.
  • Challenge your people on daily basis. Pair them together on tasks that they can teach&learn from each other.
  • Give your team members the “small” stuff they need (bigger space, another screen, better chair, more food, whatever!).
  • Praise your workers. Glorify them. If they give their best – they deserve that.
  • Treat each and every one differently.
  • Hire the best people and the best people only. yes, it is worth it. one superstar developer is better than 5 mediocre ones. Don’t believe any book or any poor manager that claims otherwise. Hack, don’t trust my words, what do I know anyway? Instead, let’s all read 100 books of XP and Scrum, miss the deadlines, release crapy code and hate our jobs. We can always blame the management. Superstar developers will build tools that can replace 10 mediocre programmers, so let them do it and give them the stage they need. Superstar developers make your company a place worth working for. Best people bring the best with them. Now, isn’t it worth paying some extra for those guys? Don’t worry, you will get your $$$ back, I promise.

So agile, in my book, is the confidence you have in your teammates and the greatness of your people and your tools. Without the best people, don’t bother doing the rest. at least don’t expect for “agile” development. The best you’ll get will be Agile Development and that’s suck isn’t it?