A nice overview of the path that has been taken for Agile to arrive in our daily thinking…
In this post, based on a LinkedIn discussion, I describe a meeting of some of the key players in Search who get into a great discussion about how running an Enterprise Search project…
It was Friday evening, and Charlie was meeting his friends for a drink. They all worked in IT and had, between them, years of experience, especially in enterprises and enterprise search, and liked to get together to catch up with what each was doing.
After a few pints and small talk, Charlie said “Guys, what do you all reckon would be the best way to build a large-scale enterprise search project?”
Martin, who had a lot of experience in this area, looked up and said, “The main thing is that you should never underestimate what is required to get the best from a search investment.”
Charlie nodded in agreement. “But how can we help the client understand what sort of a commitment is needed?”
Ken suggested using an Agile/Scrum approach for the analysis of what the client needed as well as the development of the search UI.
“Hear hear” called out the others. Otis took the chance to follow that up with “you need someone who really understands what search is all about”. Martin glanced at him and nodded. Otis carried on. “Someone who cares about search metrics, and knows what changes need to be made to improve them.”
Jan chimed in “I agree with you on some points. You‘ve got to make sure that you include all the stakeholders, and also, educate the customer. Get everyone in the same room, and start with a big picture, narrowing it down to what is actually required. And, yes, create demo’s of the search system using “real data”. It helps the customer understand the solution better.” “However,” he continued. “I’m still careful about forcing a Scrum approach on a customer that might be unfamiliar with it.”
Stephanus put down his glass. “I’ve just finished a Phase I implementation at a client. The critical thing is to make sure you is that you set the client’s expectations and get buy-in from their technical people. Especially in security and surfacing. And I agree with Jan. There are still a lot of companies that don’t use Agile, or Scrum, at the moment.”
Sitting next to Stephanus was Helge. He began to speak. “There are a few important things. Make sure you’ve got Ambassadors – people who really care and promote the project. And ask the important question – ‘How can the search solution support the business so that they can become more competitive?’ It might be necessary to tackle this department by department. Get the business users and content owners together, but as Stephanus just said, don’t forget IT. And make sure that the governance of the system is considered.
Stephanus smiled. “Yes – the workshop idea is a definite must.”
Gaston, who was sitting next to Charlie, said “An Agile approach has worked for me in the past. Creating prototypes is important. Most clients don’t know what they want until they see something tangible.” “Ok,” said Charlie, “how has that worked?”
Gaston continued “Build a small team consisting of a UI designer, a developer, a search engineer, someone from the IA team, and no more than two of the business users. Having someone there from QA is also handy. Start with a couple of day-long workshops to go over project objectives, scoping and requirements gathering. Use one-week sprints, and then aim to produce workable prototypes. At the end of the week, schedule a time where the prototype can be demoed. The point is to get feedback about what is working, and what the goal for the next sprint should be.
Mike, the last one in the group, looked around at everyone, and then back at Charlie, and said. “Charlie – there’s a lot of great advice here. One important thing to remember is that you have to work with the client to ensure that the search solution is part of the strategy. As the others have already mentioned, work with the client and educate them. Getting all the stakeholders together for some common education, collaboration and planning can really go a long way towards getting the necessary buy-in and commitment needed for a successful project. It also is great for setting expectations and making sure everyone is on the same page.”
Charlie was impressed. He had some pretty smart friends. “Thank’s guys. You’ve all had some excellent points. Let me buy you all another round”.
Martin White (who was involved in this discussion) has written a book – Enterprise Search: Enhancing Business Performance. You can check it out on Amazon here.
Interesting Resources
Want to learn more?
(Important Disclosure)
In my earlier posts (here, here, or here) you can read how I have recently “discovered” Agile/Scrum
Having seen the challenges that can be encountered with the Waterfall, or PRINCE2, model, I am keen to learn more about this alternative approach. To that end, I sent myself off on a Scrum Master course.
In this post I want to give my impression of the training course – what was good about it, what worked, what didn’t, and what was wrong with the course.
Before I do, I need to clarify that these are my own opinions and not those of my anyone else that I have regular, or irregular contact with.
Also, please note that I won’t be going into the merits, or shortcomings of Scrum. I won’t be entering into the “discussion” taking place in the Project Management community surrounding the Scrum Master Certification. Nor will I be giving a blow-by-blow account of the 2 days.
Course Name: Certified Scrum Master Course
Course Provider: Collabnet – a reasonably large company that specializes in collaboration software development. Agile training is also part of their offerings, and they give courses in multiple locations in North America and Europe.
The training course was help in a conference room in a Marriott hotel. This meant that there were excellent refreshments, and a great lunch. (Always an important factor when attending such an event.)
For this course, the trainer was Rafael Sabbagh Armony.
I was very impressed with his style of teaching he used. The training material he gave us seemed to be merely a formality as not once did Rafael refer to it. His style was more an interactive one. Through a series of “group exercises” he created an environment of learning through exploration, questioning, and peer-learning.
Obviously, a group exercise is a very contrived event and has very little resemblance to a “real world” equivalent, but in the process of working through the exercise, it encourages one to relate it to other situations (perhaps ones that are based in the real-world). This fostered further questioning, and discussion (both within the group, and within the whole class.
Rafael seemed very knowledgeable in his subject (Agile) and drew upon real-life situations that he had been involved in, when discussing SCRUM, both in answering individual questions, or contributing to one of the many class discussions.
On the understanding that the course was focused on a Scrum Master, and was not an overview of Agile, or even Scrum itself, I did feel that, at the end of the course, I had a far-better understanding of this Framework.
One interesting thing was that, after registering for the course, I received access to a collection of on-line Scrum training material. This included a Scrum quick-reference guide, and a series of training videos, that took me through the fundamentals of Scrum.
Knowing very little about Scrum at this point, I found these resources to have a lot of value. It also meant that, during the training course itself, time was spent with “group exercises” (see above), and discussion, rather than going through the basics.
On the first day of the class, we were each given the course notes. These were in color (always helps), but had a thermal bind cover on them. While keeping the pages together in a very tidy fashion, it meant that for you to lay the “book” open fully, you had to damage the spine and binding material.
While Collabnet describe themselves as “The Leader in Agile Development in the Cloud” they came across as a organization made up of business units that seemed to have absolutely no idea what the other business units were doing. They also didn’t appear to have a coördinated approach to dealing with customers.
My point in case is this: On the 6th of December, I registered, and paid, for this course, and immediately received a confirmation from the department that handles course registration. This was as expected. However, on the 12th of December (less than a week later) I received a promotional e-mail from Collabnet offering me a 40% discount if I “book now!”
I was furious. A 40% discount was quite a lot (especially when I was, indirectly, paying for the course myself). I contacted Collabnet and asked why I wasn’t told about this when I first registered, and requested the same discount. The response I got was a simple “Sorry – we can’t retroactively apply the discount”! Unbelievable! (Maybe I was asking the wrong person, but then I would have expected my e-mail to be forward to the correct person, and to get a response from them.)
And to make matters worse, I still receive “promotional” announcements on a regular basis.
One would expect any company that is involved with the “Cloud” to be socially aware. They do have a Twitter account (@Collabnet), but seem to use this merely as a “hey – look at us” type of account. I sent out a tweet about the 40% discount “complaint” I had, and even included “@Collabnet”. Did I get a reaction? No. This gave me the impression that Collabnet were not responsive to their customers.
The training notes were full of typographical errors.
At the time, this did not cause too much concern (My recommendation is to check out something that most businesses that provide material to customers, and the public – a spellchecker. It doesn’t take long to do it, and, in many cases can be initiated by just clicking on a menu item.
The fact that there were many, many spelling mistakes is, in this case, not of too much concern. As I mentioned above, Rafael delivered the course without referring to the notes, and did it in such a way that the real value came from what he was saying, rather than what we were reading.
However, having words incorrectly spelt (especially in your course material) does send a poor message. And it does not take long to run a spell check over the content before “publishing” it.
With regards “images” – I have only one small complaint – make sure the images used don’t cover up the text (especially when they are being used on a page that discusses “transparency”).
Overall, I was satisfied with the course.
Having the pre-course training material available was excellent. I was really happy with that.
The classroom training, as delivered by Rafael, was also very good. I did not walk away at the end it feeling unsatisfied. The method of delivery was great, Rafael didn’t just “read from the book”
However, the “Bad” points I mentioned are worth thinking about. Collabnet came across as a Big Company that didn’t really care about its little customers.
Matthias Marschall made a comment on my post “SCRUM – are there actually any rugby balls to be seen?” where suggested that there is a movement to replace SCRUM with Kanban.
there is a movement to replace SCRUM with Kanban
I plan to look into this more. In fact Matthias also shared a link with me titled “SCRUM vs. Kanban“. While it is still on my “to read” list, it certainly bought my attention to “Kanban“.
Then today, I saw this cartoon at the blog site of Crisp Consulting, a company that is really into Agile. (I recommend you check out their other blog articles.)
Having looked at this I’ve started wondering….
I’ve signed up for a SCRUM course. Yeah – I want to learn more about it…
There is some pre-course “reading” to be done (actually some training videos). Now, I actually like the whole idea of SCRUM. That is – you can’t get users to define all their requirements at the beginning of a project. In the cases of new technology, users don’t know what they want until they see it, so asking them for their “clearly defined” requirements at the beginning means a world of pain once you get further done the line.
So, it was with a lot of enthusiasm that I sat down, and watched the training videos.
While I still agree with the principle of SCRUM, the “names” given to “normal” things, made me smile.
In fact, it made me think of me think of Jordan Bortz’s excellent post “Howto: Create and Promote a new (but popular) Agile Methodology“. In this he takes a slightly irreverent look at this methodology.
Also Software Maestro hit the nail on the head with this one – “SCRUM Master Jar Jar“
Other useful links
In an earlier post, titled “The Fast and the Furious – SCRUM“, I talked about how I had discovered that there is another way of doing a project than following a waterfall approach. And this new way was called SCRUM.
Yeah – I thought a scrum was something that a bunch of large men did while disputing ownership over a small oval ball. Well, turns out that, actually, there is actually a connection.
In 1986, two Japanese business experts (Hirotaka Takeuchi and Ikujiro Nonaka) published a paper in which they describe the (then) current product development process to be similar to a relay race with one group of functional specialists passing the baton to the next group.
What Takeuchi and Nonaka proposed was a different method where “a team tries to go the distance as a a unit – passing the ball back and forth”.
And this was the basis of what we know call the SCRUM methodology og project management.
You can read their paper here.
Other Great Links
In a recent post on SCRUM, Adrian McGrath made a comment about the use of a “Model Office” approach for gathering requirements for systems. A Model Office approach is also useful for encouraging user acceptance.
This piqued my interest…what is a “Model Office”?
In comparison to the “Waterfall” method, which involves capturing requirements, designing, building, testing and deploying, the “Model Office” approach offers a far more “collaborative” way of designing a system.
the “Model Office” approach offers a far-more “collaborative” way of designing a system.
Adrian McGrath has written an excellent post on the “Model Office” (see link below). In it he points out that the success of an implementation is heavily dependent on the uptake of the solution and buy-in from the user base, and further to that, during requirements gathering, most users “don’t know what they don’t know”.
By using the Model Office approach, the “end product” is created, and the users are allowed to interact with it and become familiar with it. Changes are made iteratively until the end-solution is something that the end-users are happy with.
My initial reaction to the “Model Office”
Most of the large projects I have been involved with have made use of the “Waterfall” approach.
As a result, in my mind, the “correct” way of designing a system was first to get the users to define their requirements, independent of any specific end solution. Then a suitable solution was designed that would meet these requirements.
Even though I had discussed SCRUM methodology earlier, I didn’t think that it was suitable for a large system, which required a more formal approach to design & development.
However, as Adrian pointed out – “a user doesn’t know what he doesn’t know”. This makes me think about Henry Ford’s quote “If I’d asked customers what they wanted, they would have said ‘a faster horse’.”
When dealing with new technology that offers a totally different way of working, it is a bit unfair to ask the users for requirements. Often they can only describe what they want in terms of what they know. This means there is a risk of missing the full potential of a system. And, as Adrian also mentions, it means that the adoption of the new system by the end user is very slow.
And, in terms of the “Technology Acceptance Model“, because the user has not been truly “involved” with the design process the “perceived usefulness“, and the “perceived ease of use” are not great.
Taking this all of this into consideration, I find the concept of the “Model Office” an exciting one. I can certainly see advantages of it in terms of user adoption.
“Model Office” Resources
Recommened Reading
(Important Disclosure)
One thing I used to hate was working on Projects that had no “definition”.
They were usually just a case of stumbling along, hoping that everything was going according to plan (not that there ever was a “plan”). And then working madly at the end to get something that was close to what a sales person had promised a client.
Then I learnt about a more methodical way of carrying out a project. A way that ensured that the project was:
This methodical way ensured that the correct documentation was created at the correct time, and followed a suitable life-cycle. Very much based on the PRINCE2 methodology.
And I liked this way of doing a project. It had structure. And is still very relevant and appropriate to many situations.
Recently I have become more aware of the SCRUM method.
Originally I thought it was to do with the sport Rugby, and since I was brought up to worship the All Blacks (part and parcel of the culture I grew up in) I was surprised that SCRUM, in this case, had nothing to do with men in rugby jerseys fighting over possession of an oval ball.
No – SCRUM, it seems, is a “different” way of doing a project. The more I read about it, the more I thought “hey – this makes sense!”
Like PRINCE2, Scrum also has a set of practices and a set of predefined roles.
PRINCE2 has it’s Executive, Key Customer and Key IT board members.
SCRUM has its SCRUMMaster, Product Owner and Team.
Further to that, while PRINCE2 is a process-driven project management method,
SCRUM is reactive/adaptive method.
This is highlighted by the fact that the SCRUM methodology involves several sprints – periods of two to four weeks – where the team work on creating a potentially shippable product based on high-level requirements.
This way of working is not suitable for everything.
Just imagine a company building a motorway, or a high-rise building, where every four weeks that make changes based on “high-level” requirements. In those situations, you do want your processes.
However for smaller projects, such as developing a corporate portal, or similar, the SCRUM methodology seems to really make sense. Especially when you are relying on requirements from users who don’t really understand, or know, what they want. In this case, the build it, and then “rebuild/modify” based on feedback is a faster way of working.
Recommended reading
(Important Disclosure)