Archive

Archive for the ‘Agile’ Category

Definition of DONE of an Agile Transition.

August 31st, 2010 pyxis posts profile No comments

Any questions?

Share/Bookmark

Ayez le Scrum Robuste!

August 27th, 2010 gael luisier posts profile No comments

Scrum n’imposant rien sur le plan technique, une dérive couramment constatée est un manque de rigueur par rapport aux pratiques d’ingénieries utilisées par les équipes de développement.  Par exemple, l’omission de tests automatisés lors de l’évolution de projets informatiques rend généralement de plus en plus difficile l’atteinte de l’objectif de livraison de qualité “production” au fil des itérations. Martin Fowler a nommé ce phénomène le Scrum Flasque.

Le cours “Professional Scrum Developer” offert à Pyxis vise à contrer ce problème en replaçant l’emphase sur les bonnes pratiques de développement essentielles à l’atteinte des objectifs de Scrum.

Le développement piloté par les tests (TDD)

Nous avons pu mettre en pratique le TDD dans toutes les facettes de l’application, aussi bien pour le développement en tests unitaires qu’en tests clients (bout en bout).  Ceci nous a permis de nous rendre compte qu’il est possible de couvrir la quasi totalité du code par des tests automatisés.  En conséquence, le code obtenu est robuste, explicite et diminue le stress du développeur qui sait que ses changements seront plus faciles à implémenter dans le futur.

Choix technologiques

Certains choix technologiques peuvent rendre difficile, voir impossible l’application des bonnes pratiques et donc l’objectif de Scrum Robuste: la livraison itérative de logiciel de qualité.  Il est par conséquent essentiel de choisir un ensemble d’outils (langages, cadres d’applications, environnements de développement) qui supporte convenablement ces pratiques.  Un exemple parmi tant d’autres, le cas d’utilisation étudié durant la formation utilisait une librairie de rendu visuel légère et testable.  Ceci nous a permis de facilement tester les vues de manières unitaires, ce qui est malheureusement rarement possible…

Elimination des mauvaises odeurs de code

Les mauvaises odeurs de code (aka Code Smells), comme par exemple les duplications ou les classes géantes, sont des causes fréquentes de difficulté à maintenir une base de code et d’une réduction de la vélocité des équipes.  Le cours nous a permis dans le cadre de la pratique du TDD, de veiller à enrayer en continu, par le “refactoring”, ces mauvaises odeurs.

En conclusion, il faut garder à l’esprit que Scrum ne suffit pas en soit à livrer du logiciel de qualité.  Scrum doit nécessairement être entouré de bonnes pratiques de développement, telles que celles enseignées durant la formation pour éviter de sombrer dans la flaccidité.

Allez-y, soyez robustes du Scrum! :)

Marc-André Thibodeau et Gaël Luisier

  • Share/Bookmark
Categories: Agile, Développement logiciel, Scrum Tags:

Between a rock and a hard place – The managers in an agile transition

August 26th, 2010 martin proulx posts profile No comments

Image by NCM3I bumped into Steven last week. Steven is director of application development in a large organization and like most manager in his early forty’s, he looked tired and although he is usually a happy individual, his smile wasn’t radiant this time.

In agreement with his teams, Steven initiated an Agile transition a few months ago. I was part of the team who presented to Steven the benefits of a transition and the impact on the team members and their managers. I saw Steven again in a group training I was giving a few weeks after the beginning of the transition to managers and executives. That time again, Steven was very excited and motivated about what he was hearing, except that during the training I could see the light bulbs over his head and in the questions Steven was asking – how is this going to impact my role as a manager? Steven saw the obvious benefits and understood some of the changes he would need to make to his leadership style but I could tell, it hadn’t fully sinked in.

So here we were, less than 3 months in the transition and Steven wasn’t as chipper as he used to be…

  • Me: “Hey, Steven. You look tired. How are you doing?”
  • Steven: “I’m OK… I’m tired… [silence] The transition is killing me!”
  • Me: “How so?” [I asked anticipating what he would tell me next]
  • Steven: “The team is having a blast and I can see their performance has increased compared to the past but I don’t think I can cope with this new approach”
  • Me: “You seemed so excited about the transition when we started. What changed?”
  • Steven: “I now realize what you meant when you talked about changing my leadership style and my role. I’m still up to the challenge but my boss is totally clueless about all of this”
  • Me: “What do you mean? Haven’t you brought him in the loop from the beginning?”
  • Steven: “Yes. Yes, I have but that’s not the problem. The team’s performance increase is directly linked to the new approach they have been using and the fact that I leave them a lot of autonomy but my boss still asks me to behave like I used to – like he manages his team today. That’s where it hurts the most. I can pretty much deal with everything else but I feel like I’m stuck between a rock and a hard place”

Unfortunately, we (as consultants) do not do such a good job at highlighting this fact before we begin a transition. We work closely with the teams to help them adopt better methods and practices, to increase their overall performance by allowing them to be self-organized. We work on getting the teams to a highly performing level. Then we go get executive sponsorship to secure the initiative (and the budget) and make sure we get support to handle difficult issues but what about the people in the middle?

We develop training programs for Agile managers and we support them with organizational coaching but we don’t do such a good job at telling them upfront how much pressure they will be under once the transition begins. How much their role is likely to change and their leadership style needs to be adapted to the new reality.

For those who haven’t yet have felt the pressure, here are some examples of what to expect:

  • You may be willing to trust your team and let them self-organize but is your boss in agreement with this new approach? Will he be as involved (micro-managing) in your activities as he used to be? And more importantly, will he be expecting you to be as involved with your team as you used to be?
  • You may be willing to tolerate mistakes in order to increase your team’s learning and with a strategic perspective to increase long term performance but will you hear about your inabilities to control your team during your next performance review?
  • You already produce status reports, dashboards, emails and others information to keep everyone (including your boss) informed of what is going on in your unit. Will you need to translate everything that the Agile team is producing to fit the traditional reporting mechanisms? Can you challenge what information is currently being produced to ensure it does bring value to people?
  • You expect your team members to handle the details of their activities and you believe in actually seeing (touching, feeling) the end results while your management team expects you to assess progress using Gantt charts. Do you need to educate your entire organization to the new approach? Does the fact that you are adopting Agile make you the evangelist for the entire organization?

Obviously, I don’t mean to scare anyone – especially the managers – with regards to adopting Agile. The approach has a lot of merit and value for many organizations but in order to help with adoption, coaches and consultants need to pay attention to the people in the middle and help them find their new place, otherwise we are very likely to find serious resistance and potential failure of such initiatives – nobody likes to be stuck between a rock and a hard place…

Share/Bookmark

You might be interested in these related posts:

  1. What consultants don’t tell you before you begin an agile transition – Part 3: Impact on the functional and people managers
  2. Agile Transition – What about the teams outside the transition?
  3. Secret Revealed! Guaranteed Success for your Agile Transition

Where is the turtle heading?

August 26th, 2010 dominic danis posts profile No comments

Now that the vacations are over and that the 2010 Agile conference has come and gone, Team Urban Turtle is back to work, cooking up another promising release 3.4.

With the release of the Scrum template from Microsoft came a Removed state, making it necessary to propose a recycle bin feature to our users. The next version of Urban Turtle will therefore include a recycle bin icon at the top of the iterations and areas panel. Users will be able to drag and drop items onto it to set the state of selected items to a configured deleted state. It will also be possible to view deleted work items by clicking on the icon.

The team is also working on a select / unselect all option to flag or unflag all iterations and areas as favorites in one click.

We have several more interesting features in our backlog, some of them coming from customers who voiced their opinions and proposed suggestions on our community-powered support site. Thank you all for your support and keep those suggestions coming!

} Dom

Post to Twitter Tweet This Post

Lean Startup: Interesting conference by Eric Ries

August 25th, 2010 joël grenon posts profile No comments

There will be an interesting conference on Lean Startup by Eric Ries at SXSW. Eric asks 5 questions everyone involved in building new products (or any market offerings) should ask frequently. Answering these questions is not as easy or obvious as it sounds. It’s even more important for mobile development as product lifecycles are very short and spending too much effort on a bad or average product might have high impacts (opportunity loss). I’ll reuse these questions in coming blogs and apply them specifically to the mobile market. To read these questions and vote for Eric panel, visits http://panelpicker.sxsw.com/ideas/view/8270

  • Share/Bookmark

Agile 2010 Conference – Day 1

August 24th, 2010 pyxis posts profile 2 comments

I went to my first Agile Conference!  I guess I’m always a bit uneasy when I’m surrounded by people who more or less think the same way I do. On the other hand, it feels great! It’s a stark contrast from what I’m used to – you know, being surrounded by Architects, DBAs, PMOs and project managers who a waiting in the wings to save the day when this “Scrum thing” fails.

So for five days, I dove in the pleasant warmth of my fellow agilists and shared ideas, laughs and a few drinks.  Attending the wide variety of sessions was my preferred activity and a great opportunity to listen, participate and learn.

Enough chit chat, let’s get right into it…

My first session was “Leader’s Workshop: Making Change Happen and Making it Stick” with Mary Poppendieck.  I won’t go into details so here are a few points…

Mary states that to encourage change, one needs to provide:

1-      The proper kind of motivation

2-       A clear direction

3-      A supportive environment

So what motivates people?

Mary references books such as Switch, Drive and that great video by RSAnimate

A very interesting point is to manage employees as if they were volunteers.  With money being out of the equation, what needs to put in place and maintained to keep motivation at a high level?  What  keeps a volunteer motivated?

  1. A  clear purpose
  2. Structure and guidance
  3. Successful project
  4. Ownership
  5. Autonomy
  6. Bragging rights
  7. Mastery
  8. Constructive dissonance

What I take back from this session

You can throw all the cash you want at your problems and they still won’t go away.  If you want successful projects, hire smart people, offer them a clear direction, a few rules, and get out of their way.  Smart people will find a way to make it work.

Share/Bookmark

Lean Startup : Early lessons from the market

August 23rd, 2010 joël grenon posts profile No comments
Our knowledge acquisition strategy for ACS Cloudphone is starting to pay off. After only 3 days of MusyMix on the market, we already gathered good information about ACS: No one has installed the ACS CloudPhone after installing MusyMix. Most probably, the relationship between the advanced transcoding feature and the ACS CloudPhone has not been correctly identified. The result, users get invalid format errors and MusyMix is less useful to them.
A solution would be to display a dialog box upon MusyMix start to ask the user to install CloudPhone. But then, they would have to create an ACS account before using MusyMix, which is a lot of overhead before being able to fully use the app.
In addition to this, ACS isn’t stable enough yet. While it’s working relatively well, we haven’t made any scalability tests and the full-duplex communication channel between the phone and the cloud is very tributary of the quality of the network connection. We have improved, but that’s still more complex than perform a simple HTTP request when the user need something. Continuing on this path, we slow down all dependent applications, which isn’t a good move.
To add to this, ACS is a very horizontal product, a platform. With our lean strategy, we aims to deliver frequent releases, but for a platform, that’s very challenging. We did well up to now, but we think that by focusing on putting specialized cloud products, based on the platform, on the market, we will generate more revenues and gather more meaningful feedback.
After having announced the transcoding feature, we got a lot of positive feedback from the Android community. So focusing on building a strong and autonomous transcoding offer on ACS would serve MusyMix and would help ACS get traction on the market. So our next ACS move is to create the ACS Media API, a cloud transcoding offer usable from your Android phone (or other media). This service will be part of the ACS platform, but will be marketed separately (specific landing page, adword campaign, etc.) We will develop this service separately but use the same account and payment data than the ACS platform. Instead of providing a different application to access ACS, we will add a few activities through our client library to configure the ACS Media API. This is a marketing repackaging of the same implementation we did in ACS. This will be quickly assembled and integrated to MusyMix and than, the product itself (in BETA) will be launched early next week. This week should be very active for MusyMix. We’ll continue to gather feedback, hopefully reach 500 users and learn more usage patterns. We need to get this transcoding feature solved quickly to keep our user base happy.
  • Share/Bookmark

Agile in a Command-and-Control Organization : What to do when upper management forces overtime?

August 22nd, 2010 martin proulx posts profile 2 comments

Image by MyLifeStoryMy colleague François Perron launched a very interesting discussion on our private wiki – “As a coach, what to do when executives and upper management force the project team to do over time in order to meet deadlines?”.

As you can probably guess, this initiated very interesting discussions and an obvious reaction to such an approach.

Everyone agreed that due to the project visibility and the position of the organization within its market, the project launch date was critical. Everyone also understood that the organization had very few options so nobody debated the need to achieve results. The discussion was strictly around which measures to use in an Agile context.

I’ll admit up front that I am biased toward intrinsic motivation (I really loved Drive by Dan Pink) and the fact that it is well suited for an agile environment.

As such, my first impression to the conversation that was going on were:

  • Does the organization wish that employees spend more hours at the office (attendance) or would they prefer more engagement (commitment)?
  • If their choice is to increase the hours of attendance, imposing overtime will achieve this goal while giving them a false sense of increased performance. People will show they are working longer hours but the real throughput is unlikely to be much higher. In addition, software development is a brain intensive activity and reducing the amount of rest people get is likely to increase the number of mistakes they make.
  • On the contrary, if the organization wanted more involvement, the inclusion of team members in determining the best way to achieve the results would probably come to a better decision – even possibly leading the willingness to do over time

It appears to me that by forcing overtime, the executives and senior managers will probably collect their bonus and congratulate each others in the short term only to realize in the longer term that they have simply pushed the problem forward for others to deal with – and possibly request more over time in the long run.

Share/Bookmark

You might be interested in these related posts:

  1. I don’t feel so good – I’m a people manager in an Agile organization
  2. Does your organization support prostitution?
  3. Defining Agile Management – part 1

Lean Startup Applied to ACS

August 18th, 2010 joël grenon posts profile 2 comments
For this posts series, I will talk about our strategy for Android Cloud Services, our mobile-cloud platform that seamlessly extends any Android phones running version 2.1 or more. ACS is a complex platform and is more of a horizontal capacity than a specific product solving a specific problem. This is a product, we aim at selling cloud resources through a micro-transaction model, but for now, the platform is not ready to be opened to the world wild web and not rich and stable enough to cover all potential uses. This is a future product that we have to mature in the coming months for it to emerge as a solid revenues stream for next year.
But more than just maturing, we want to apply lean startup principles to discover what’s the real killing feature of this platform. We have ideas, we think we know what will work and what won’t, but thinking is not enough. We want to quickly test our hypotheses in the market and get any feedback we can from early adopters. If we can’t open the platform to fellow developers out there, our only choice to get the necessary feedback is to build our own applications on the platform and gather indirect feedback on how it’s used.
We already have four Android applications built on the ACS platform, only one being available on the market: CloudPhone. We know for sure that CloudPhone won’t be a popular application today: it doesn’t do anything useful! It’s just a router to the ACS cloud, abstracting all ACS protocols to other client applications. We decided to launch a minimal version of CloudPhone to the market, to ensure that when we develop another client application, it’s easy to find and install. It’s a mandatory dependency for any ACS compatible application. The other three applications are open-source and simple prototypes accessing various cloud features.
This week, we will launch a first version of MusyMix, a simple music streaming player built on ACS and using 8tracks.com as music library. This is a minimum viable product that focus on getting 8tracks members with Android phones to listen to music mixes anywhere. So our target market is basically 8tracks.com 100K visitors per month who own an Android phone. We think we can easily reach 5000 persons, assuming that a few Android users will try it without an 8tracks account (not required). For ACS, we want to validate that people understand and are willing to install the ACS CloudPhone. This will give us quality data to improve our next move. We’ve integrated Flurry Analytics in both applications to ensure we get the right information, quickly.
The key point is that MusyMix may be used without ACS. This is important because we want people to understand why they need ACS and what problem it solves. Actually, this is an Android platform problem where the native media player is unable to stream M4A (iTunes) content. Using ACS, we perform the audio transcoding on the cloud, in real time, before returning the audio stream to the media player. Without ACS, you get plenty of errors, mostly because 8tracks.com content is built by the community from their local iTunes library (not normalized).
So we go to the market, quickly (less than 2 weeks) to learn what features is missing from MusyMix, which in turn will provide us insights on our evolving cloud platform. This will shed some light on our ACS target market and help us guide our next moves, without wasting too much time developing features we think will be marketable.
  • Share/Bookmark

Applying Lean Startup principle to Android application development

August 17th, 2010 joël grenon posts profile No comments

Creating good and successful mobile applications is something you learn from the market, not by reading books on how to do wonderful technical tricks on the phone. But getting an application to market is a complex endeavor which requires a level of polish to avoid bad ratings and thus, killing your good product before its even used. So, even more for mobile apps, getting to the market fast and providing constant releases with small improvements to your customers is a key to success. Agility helps us on two axis: customer development and product development.

Knowing quickly who (and where) are the customers willing to pay for your app is another key to success. You may perform educated guesses on where they’re hiding, but the best way to find your customer is through trial and errors. You have to craft a message and quickly get it to your potential customer, measure their interest and adapt your strategy. Chances are that for the same product concept, you’ll have 5 or 7 (or more) customer development iterations before you nail down your most efficient market strategy. It means that while you’re finding your target, we don’t focus on the code or technological aspects at all. We just build what’s sufficient to fulfill our market experience. Of course, through good engineering practices, you may build flexible products that may be quickly adapted to your market needs, but the market must be prioritized over the technology. If you have to rebuild everything to succeed, just do it.
To avoid unnecessary waste, you must thus perform very small iterations. In the worst case, if you have to discard your work and make a 180 degrees turn, you’ll minimize the amount of work you’ll be wasting. You have to organize your activities around delivering fast releases to your potential markets, broadcast the news and measure the result while you’re already started your next iterations using a different angle. Depending on your product, you might look at daily cycles or even continuous deployment approaches. For Android applications, we have the capacity to deploy to the market as often as we want (many times a day) as there’s no complex approval process. This is a good environment to apply lean startup principles and learn from market feedback. For small teams or other platforms, market cycles of 1 or 2 weeks may be good enough, but just remember that you’ll still need a few cycles before nailing down your target market positioning. The longer the cycle, the longer the discovery phase, the higher the cost of your product.
These principles and practices have emerged around the Lean Startup movement. In the coming weeks, we’ll be applying these agile principles on ACS derived products and provide a complete walkthrough and experience return on this blog. Stay tuned!
  • Share/Bookmark