Let the version numbers role. In case you missed it, people are putting version numbers to the internet as it’s some sort of application. I suppose that’s what technology folks do to differentiate concepts. Unless you’ve been living under a rock or still styling your member’s only jacket there is a concept out there called Web 2.0 which in my opinion in one word means, community. Everyone’s doing it from pharma companies (as long as you can get past adverse event reporting) to FOX to your grandma who posts a blog based on her travels and cookie recipes. That said - Enter Web 3.0.
Some smart folks over at Yahoo seem to have a formula down for what Web 3.0 looks like. It goes something like this
Web 3.0 = (4C + P + VS).
3C = Content, Commerce, Community 4th C = Context P = Personalization VS = Vertical Search
I happen to agree with the later and believe context will drive the next version of business services, marketing programs and public websites. It’s now main stream to have a MySpace or Facebook account. Google is working hard on customizing searches via Local Search, digitizing hoards of books, and providing you different avenues to shop, but not many systems are effectively providing artificial intelligence a.k.a 4th C; Context. The Semantic web as many refer to Web 3.0, is a place where machines can read Web pages much as we humans read them and deliver information through handhelds and browsers that you actually want.
Below is a reinvention of what Sramana Mitra has already intelligently portrayed on a personal shopper sample. I’ve taken the idea and put a spin on the article, as it relates to Web 3.0 and the pharmaceutical/biotech industries.
Imagine….
- I am a respected oncology sales rep (a rep of the future) located on the east coast who works for a major biotech organization. (Context)
- I want my personal online toolkit to provide the ability to purchase reprints, download vis-aids and access an ordering system for samples. (Commerce)
- I also want to be able to have medical conversations with physicians through an interactive online tool based on therapy and disease state. (Content)
- I want to collaborate with my west coast colleagues through my wireless device as I’m in-between visits to see how they handle certain questions from oncologists. (Community)
- Once I learn of an approach from a colleague, I want to prep for my next visit by searching online publication bases by author, subject and MeSH heading to familiarize myself on small cell lung cancers. (Personalization, Vertical Search)
Now, imagine the same for a pharmaceutical sales rep who relies simply on doctor visits. and he doesn’t have a clue on how to perform even the simplest search online. Before Web 3.0, he/she could get all vis aids and searches through a department at his company.
With Web 3.0, the internet will be his new department providing lean process and cost savings to the company and hopefully impacting the cost of drugs that consumers see likewise adding value to the physician so he/she can make informed clinical decisions.
As well depicted Sramana Mitra’s formula, I think 1 critical thing is missing. Give me an “I” for Interoperability (or Integration) That said, I’d suggest appending the model as
Interopability = Web 3.0 = (4C + P + VS).
3C = Content, Commerce, Community 4th C = Context P = Personalization VS = Vertical Search I = Interoperability
Content, Commerce, Community, Context, Personalization and Vertical Search are all governed by Interoperability of systems. There is no 1 mega system or service that handles all the endless possibilities. From my perspective Web 3.0 comes down to 1 word…Interoperability, the infrastructure that allows systems and applications to be artificially intelligent.
Showing posts with label Agile. Show all posts
Showing posts with label Agile. Show all posts
Increase your Agility
Lessons Learned from Integrating Agile via Scrum
You may recall a post titled “Software Implementation Nirvana” which dealt with the common pitfalls associated with full life cycle development or SDLC (akaWaterfall). Agree or disagree with my position, it is clear that organizations and groups are adopting “lean” development techniques such as Scrum. According to the Agile Alliance adoption of Agile frameworks within organizations has increased by 24% over the past year and a record number of participants have attended user conferences, up 45% since 2006. Fad? Maybe, but I believe there is more to it. Though I’m partial and believe in Agile/Scrum and have seen it in motion, this post will hopefully help you navigate the waters if you’re thinking about implementing. I wish I would have known some of these before I got started.
Lesson 1 - Scrum is a state of mind.
Your either republican or democrat. You eat meat or you don’t. You like cats or hate them (I hate them). You accept Scrum or you don’t. Scrum isn’t for everyone. I’ll say that again, it’s not for everyone. If you’re used to rigid process and everything being completed at the end, it’s not for you. If you’re working in a regulatory environment, it’s probably not for you. If you’ve got a mix of believers and non-believers, proceed with caution. Nothing brings down the adoption of Scrum into an environment more quickly than the “negative voice”. If those negative voices exist, you will be challenged to implement however not totally crippled. What you need to do is get alignment. Agree or disagree with the voices, if people don’t have an opportunity to buy into the process then they will never believe therefore causing noisy chatter during the process. Make sure you include the biggest nay sayers in all the discussion and make it a point to ensure their voice is publicly heard. Needless to say don’t forget to get that all important executive buy in. If influential juggernauts are not pushing the initiative from top down, you’re doomed regardless of the intentions within the team.
Lesson 2 – To off shore or not?
This question is like asking my son…”Do you want ice cream?” Regardless on how I phrase the question, the answer is yes. I think the questions we should really be asking re:off shoring are a) how you prepare to offshore and b) what roles need to be onshore? If you’re in corporate America, you know there is a trend to save costs which usually equates to off shoring resources. Regardless of your opinion on the matter and regardless of your previous experiences with off shoring you’ll have to learn to deal with communication barriers that exist when dealing with an offshore team if you try to implement Scrum. A few things to remember, patience, don’t degrade, people at your level even thought they don’t make as much money. Treat them with respect and with patience and you will reap the rewards. Learn the culture. If you’re working with and off shore team in India, there’s a whole cast system the pervades the team regardless of role. Take a moment to understand. Also you’ll have to realize to get effective leadership you will most likely have to use a management team onshore. But I’ve seen some odd decisions when people are trying to save money.
Lesson 3 – Does this Sprint look long on me?
Conventional wisdom and all the experts dictate that iteration (aka sprint) should not exceed 4 weeks. In general this is the case, but if you’re Product Owner is plugged in and has context, and the programmers are flying, let them get as much done as possible. The dividends for more accurate functionality will typically outweigh your progress translated out of context from a burndown chart. Key here is making sure the Project Manager keeps all parties aligned and informed.
Lesson 4 – Scrum off the shelf
Just to clarify that Scrum is a project management philosophy within the Agile philosophy. As I said Agile and Scrum are a state of mind. Scrum has roots in lean process management therefore Scrum adapts and adopts continuous improvement within itself. The core tenants of Scrum allow for change in process as long as teams collaborate. Said differently, you don’t have to change it, Scrum will most likely adopt to you.
Lesson 5 – Do we still need testers during Scrum?
Most Agile experts will dictate that test driven development (TDD) is the way to go when testing Scrum projects.. I happen to agree but with 2 caveats. First the programming team should adopt some type of XP skillset (ie Pair Programming). Second there should be a regression testing suite such as the xUnit family. Don’t forget all the scripts for previous development! If you’re shop is like most, the 2 caveats are not reality. A solution to this lack Scrum governance is to adopt some type of derivative of TDD that works for you. The key is to have a strategy on how to perform regression tests, because if you’re moving at a high velocity, the amount of time to regression test is just not built into the sprint. And let’s not forget unit testing. Unit testing is also key to Scrum testing.
Lesson 6 – Psychotic Project Management
Project managers will make or break your Scrum development initiative. A Scrum Master’s (aka Project Manager) role doesn’t change much from a traditional one. They are there to facilitate things and make sure impediments are removed. The key change here is how the project manager tracks progress via burndown charts etc. Lesson learned here, all project managers are not the same. A tactical manager used to plugging in numbers into spreadsheets is not the breed you need for Scrum. You need dynamic thinkers and leaders.
Lesson 7 – Garbage in = Garbage out
Many people tell me those systems developed using Scrum are not scalable b/c no forethought is put into the architecture. I simply respond, if you have good developers it systems developed using Scrum are. Doesn’t matter how good your processes are, if people who developed them cant make it object oriented and scalable, the process will not be scalable thus business clients will not see the value long term value. Simply said bad programmers create bad code.
Lesson 8 – Were you successful?
Success will be measured by your performance objectives which typically are measured by the “Requirements Burndown”. If a team has completed all the requirements within an iteration why wouldn’t they be successful. Don’t get caught up in the budget debate, because the amount resources cost are typically constant.
Lesson 9 – Retrospective isn’t just a buzz word
One of the simplistic beauties of Scrum is the ability not only to realize what continuous improvement is, but adopt learnings almost immediately after the completion of a sprint. Given the teams are self managing; it’s a wonderful thing to see improvements come to life in subsequent sprints. It’s almost as everyone on the team understands the context of the improvements and the approach the team members are taking. This part of the process is my favorite as it’s like a marriage, it gets better with time. Just like those of you who have a significant other and can read their mind so to speak, the same begins to happen after the retrospectives thus creating a channel for continuous improvement
About the author –
Hassan Mahmud is an Principal of WEKGroup, LLC a project and management consultancy specializing in forward thinking and technology adoption within the pharmaceutical industry. He is an early adopter of lean process management and has implemented Scrum on dozens of projects and provides coaching services for organizations investigating the implementation of Scrum by providing coaching services. For more information on Mahmud and WEKGroup’s services, you can visit them online.
You may recall a post titled “Software Implementation Nirvana” which dealt with the common pitfalls associated with full life cycle development or SDLC (akaWaterfall). Agree or disagree with my position, it is clear that organizations and groups are adopting “lean” development techniques such as Scrum. According to the Agile Alliance adoption of Agile frameworks within organizations has increased by 24% over the past year and a record number of participants have attended user conferences, up 45% since 2006. Fad? Maybe, but I believe there is more to it. Though I’m partial and believe in Agile/Scrum and have seen it in motion, this post will hopefully help you navigate the waters if you’re thinking about implementing. I wish I would have known some of these before I got started.
Lesson 1 - Scrum is a state of mind.
Your either republican or democrat. You eat meat or you don’t. You like cats or hate them (I hate them). You accept Scrum or you don’t. Scrum isn’t for everyone. I’ll say that again, it’s not for everyone. If you’re used to rigid process and everything being completed at the end, it’s not for you. If you’re working in a regulatory environment, it’s probably not for you. If you’ve got a mix of believers and non-believers, proceed with caution. Nothing brings down the adoption of Scrum into an environment more quickly than the “negative voice”. If those negative voices exist, you will be challenged to implement however not totally crippled. What you need to do is get alignment. Agree or disagree with the voices, if people don’t have an opportunity to buy into the process then they will never believe therefore causing noisy chatter during the process. Make sure you include the biggest nay sayers in all the discussion and make it a point to ensure their voice is publicly heard. Needless to say don’t forget to get that all important executive buy in. If influential juggernauts are not pushing the initiative from top down, you’re doomed regardless of the intentions within the team.
Lesson 2 – To off shore or not?
This question is like asking my son…”Do you want ice cream?” Regardless on how I phrase the question, the answer is yes. I think the questions we should really be asking re:off shoring are a) how you prepare to offshore and b) what roles need to be onshore? If you’re in corporate America, you know there is a trend to save costs which usually equates to off shoring resources. Regardless of your opinion on the matter and regardless of your previous experiences with off shoring you’ll have to learn to deal with communication barriers that exist when dealing with an offshore team if you try to implement Scrum. A few things to remember, patience, don’t degrade, people at your level even thought they don’t make as much money. Treat them with respect and with patience and you will reap the rewards. Learn the culture. If you’re working with and off shore team in India, there’s a whole cast system the pervades the team regardless of role. Take a moment to understand. Also you’ll have to realize to get effective leadership you will most likely have to use a management team onshore. But I’ve seen some odd decisions when people are trying to save money.
Lesson 3 – Does this Sprint look long on me?
Conventional wisdom and all the experts dictate that iteration (aka sprint) should not exceed 4 weeks. In general this is the case, but if you’re Product Owner is plugged in and has context, and the programmers are flying, let them get as much done as possible. The dividends for more accurate functionality will typically outweigh your progress translated out of context from a burndown chart. Key here is making sure the Project Manager keeps all parties aligned and informed.
Lesson 4 – Scrum off the shelf
Just to clarify that Scrum is a project management philosophy within the Agile philosophy. As I said Agile and Scrum are a state of mind. Scrum has roots in lean process management therefore Scrum adapts and adopts continuous improvement within itself. The core tenants of Scrum allow for change in process as long as teams collaborate. Said differently, you don’t have to change it, Scrum will most likely adopt to you.
Lesson 5 – Do we still need testers during Scrum?
Most Agile experts will dictate that test driven development (TDD) is the way to go when testing Scrum projects.. I happen to agree but with 2 caveats. First the programming team should adopt some type of XP skillset (ie Pair Programming). Second there should be a regression testing suite such as the xUnit family. Don’t forget all the scripts for previous development! If you’re shop is like most, the 2 caveats are not reality. A solution to this lack Scrum governance is to adopt some type of derivative of TDD that works for you. The key is to have a strategy on how to perform regression tests, because if you’re moving at a high velocity, the amount of time to regression test is just not built into the sprint. And let’s not forget unit testing. Unit testing is also key to Scrum testing.
Lesson 6 – Psychotic Project Management
Project managers will make or break your Scrum development initiative. A Scrum Master’s (aka Project Manager) role doesn’t change much from a traditional one. They are there to facilitate things and make sure impediments are removed. The key change here is how the project manager tracks progress via burndown charts etc. Lesson learned here, all project managers are not the same. A tactical manager used to plugging in numbers into spreadsheets is not the breed you need for Scrum. You need dynamic thinkers and leaders.
Lesson 7 – Garbage in = Garbage out
Many people tell me those systems developed using Scrum are not scalable b/c no forethought is put into the architecture. I simply respond, if you have good developers it systems developed using Scrum are. Doesn’t matter how good your processes are, if people who developed them cant make it object oriented and scalable, the process will not be scalable thus business clients will not see the value long term value. Simply said bad programmers create bad code.
Lesson 8 – Were you successful?
Success will be measured by your performance objectives which typically are measured by the “Requirements Burndown”. If a team has completed all the requirements within an iteration why wouldn’t they be successful. Don’t get caught up in the budget debate, because the amount resources cost are typically constant.
Lesson 9 – Retrospective isn’t just a buzz word
One of the simplistic beauties of Scrum is the ability not only to realize what continuous improvement is, but adopt learnings almost immediately after the completion of a sprint. Given the teams are self managing; it’s a wonderful thing to see improvements come to life in subsequent sprints. It’s almost as everyone on the team understands the context of the improvements and the approach the team members are taking. This part of the process is my favorite as it’s like a marriage, it gets better with time. Just like those of you who have a significant other and can read their mind so to speak, the same begins to happen after the retrospectives thus creating a channel for continuous improvement
About the author –
Hassan Mahmud is an Principal of WEKGroup, LLC a project and management consultancy specializing in forward thinking and technology adoption within the pharmaceutical industry. He is an early adopter of lean process management and has implemented Scrum on dozens of projects and provides coaching services for organizations investigating the implementation of Scrum by providing coaching services. For more information on Mahmud and WEKGroup’s services, you can visit them online.
Subscribe to:
Posts (Atom)