Scrum in Practice: Chapter 1 – The Project

Posted on November 30, 2012 by Paul Vincent Nolasco | Comments (0)

The Project, at its core is the problem we are tasked to solve. Regardless on the approach on how it is completed: Scrum, Waterfall, Iterative, etc., there are key project dynamics that must be addressed at all times and they are what I call the “The Five P’s or 5 P’s. I know it’s cheesy… but simple mnemonics makes thing easier to remember!

The Five P’s are: Project, Plan, People, Personality and Politics.

They are the dynamics of the project since they constantly change, they affect one another, and they are crucial for the delivery team to address if they want to be successful. One of the benefits of an agile practice such as Scrum is it makes it easier to adapt and execute the solutions in a consistent and iterative manner. This is primarily because Scrum in essence is a mixture of well-defined process but with an open interpretation on its execution. This mixture of flexibility and inflexibility combined with its simplicity is what makes Scrum one of the most recognized and preferred agile methodologies.

 

Project – Either in terms of project scope, length, deliveries, or anything in between this something that will change to some degree in course of the engagement. Since much the changes affect greatly the overall satisfaction of the customer (which should be the ultimate goal of any project) there are few things that should be done as much as possible:

  • Make sure to have an open communication with everyone in the team.
    For example: During one of the sprints in the project we implemented a piece of functionality that was later discovered wasn’t necessarily needed. It required another sprint to rectify the changes. If proper communications were done mistakes would’ve been avoided and we would’ve not wasted precious sprint cycles.

    The lesson: Communication, communication, communication.

  • Always set the right expectation to the customers by being transparent as much as possible.
    For example:Our customer had a lot of features they wanted to include in the sites. Internally, everyone had doubts on being able to achieve this but we weren’t being as transparent as we should be. Halfway through the project we’ve informed them that we need to start cutting down some of the items in the backlog. Obviously, that didn’t go quite too well since they were caught off-guard. If we’ve initially set the proper expectation when the project started and informed them that halfway through the project we will assess the team’s average velocity and based on that detail we will start defining the minimum viable product then it would’ve never been an issue.

    The lesson: Clients should never expect the unexpected.

  • Everyone must take ownership and it’s essential that key team members (Product Owners, Scrum Masters, Technical Lead/Architect & Project Managers) must make decision regardless on whether it’s perfect or not. The longer the decision and ownership of the action items are postponed the worst it gets. This is perhaps one of the most important factors in any project.
    For example: Throughout the Sprints our offshore technical lead always made key decision when implementation details weren’t as clear. At times, it may not have been the perfect decision since in some cases it is overturned by our main technical lead. However in most cases the decision is correct and it made the project much more efficient regardless of the time-zone difference.

    The lesson:     An imperfect man, making an imperfect decision, with perfect timing is one of the keys to success.

 

Plan – There is no such thing as a perfect plan, if there is, it is written by a clairvoyant. Also, in any project there’ll be detours and roadblocks. If there is no plan to guide the project then it is next to impossible to know where you’re at and where you want to be. This is almost a given in any project so this shouldn’t be a surprise to anyone.
For example: Our TSC project was plan out to start with a full team on Sprint 1, that happened only during Sprint 7 almost halfway through the project. However, because we had a plan in case wherein the team is still not in full capacity we were able to adjust and focus the first few sprints on the core content of the site.

The lesson: Always have a plan; good, bad, or backup, have a plan.

 

People – The right people in the right role in a project, is as similar as having the right gear in the right position in an old-fashion clock. The clock ticks more in-tune when things are well positioned and tuned. Resourcing any project is quite a difficult task however skimping the vetting process and placing them in wrong role is a sure way of causing unnecessary drag.
For example:  One of the positions we tried to fill in in our project is the Migration Team that requires experience in CQ and Java. However, much to our dismay instead of getting developers we were forced to use business analyst that doesn’t have any development experience at all. Our main migration lead tried to teach them but it caused unnecessary drag to him that could’ve been avoided. Eventually, we decided to move the business analysts as the Migration QA Team and use some of our CQ developers to fill in the need in the Migration Dev Team. It worked, not perfect but better. The business analysts were able to adapt to their QA roles much better than forcing them as developers.

The lesson: Project resourcing is a puzzle; it is not meant to be difficult, you just find the right piece and put it in the right place and you’ll get a better picture.

 

Personality – By nature we all have different personalities. It is part of what makes the project “fun”. There will always be some sort personality clash in some form or another whether it is with a client or within the internal team. As adults, but more importantly as professionals, the only thing that we can do is respect and understood each and everyone in the team. It might seem quite inconsequential, however it is important to recognize it since it affects the overall morale of the team.
For example: In our TSC project, the main tech-lead in the client almost always hijacks any discussion and questions most of the decisions that the development team has made. We understand that it is his job to be the devil’s advocate since he is the tech-lead but most of the time the extent of the questioning borders the line of just being a pain in the you-know-what. For a while, we try to argue but it is just who he is. We accepted the fact that it is his personality and its just one of the many factors of the project.

The lesson: Everyone has a personality including you – accept it.

 

Politics – In the pursuit of life, liberty and happiness, politics is the necessary evil. It is there no matter how invisible it might seem. It can’t be avoided in any project and it become more apparent when sound decisions are not being made.
For example: One of the few things that we tried to push back to our client is using a 3rd-party tool to assist our content migration. We told them that given with the timeframe it makes it more time consuming for the Dev Team to learn a new product rather than just writing a Java program to do the migration. However, because politics can’t be avoided such that the main tech-lead in the client had convinced the upper management that the migration tool makes the whole migration much faster we were force to use it despite our best efforts.

The lesson: Politics are not just for politicians – unfortunately.

 

The project dynamics I’ve discussed will always be there. Ignoring them is not an option. Everyone in the delivery team (not just the key stakeholders) must recognize, adapt and provide a timely/appropriate response to each of them. Fortunately, Scrum is perhaps one of the best solutions to address this problem.

Scrum In Practice: Chapter 0 – Preface

Posted on November 30, 2012 by Paul Vincent Nolasco | Comments (0)

Before we get started, let us first have a clear understanding what is the purpose of this document. This is not a document that explains what is Scrum in detail. There are plenty of books that serve that purpose. My goal in writing this document is to explain the key topics of Scrum and to provide a practical perspective on how it was used on a project that requires us to implement fifteen commercial sites in the span of six months (For clarity and confidentiality sake going forward we will refer to “the project” as The Site Company Project or TSC project). There were upwards to 30+ resources with a mixture of onshore and offshore personnel. It was complex and a daunting project to say the least. And in all honesty, given with the timeframe and scope, the TSC Project would’ve been almost impossible to implement if it weren’t for an agile practice such as Scrum.

 

Scrum is less of a methodology but more of a framework. Therefore, this is can never be a How-To-Guide that you can easily follow and replicate from one project to another. It’s a framework in a sense that there are major pillar points that can be applied, with minor modification, from one Scrum project to another. Each chapter in the document explains briefly the major pillar points of Scrum as it relates to the TSC Project. You may notice that each topic are structured in a very consistent and methodological manner. This was done on purpose. It starts of with an Overview – brief key points in regards of the topic, then Examples – some actual scenario that happened through the course of the project and finally Lessons – a concise summary of what should be done going forward. In doing this, I hope that it makes it easier for readers to grasp the key details more efficiently.

 

My role in the project is the Product Owner. Briefly, in Scrum terms, Product Owner is the person that owns the product. Hence, he or she decides the definition of the user stories – the core element of scrum – that ultimately will be implemented by the development team, which eventually results to the finish product (i.e. the actual site). Besides the Scrum Master & Technical Lead, the Product Owner is one of key member of any Scrum-delivered project. Given with this perspective, I attempt to write this document in the hopes of providing a more practical perspective on how Scrum can be used.

 

In the end, hopefully in some way this helps you in your current or potential project that uses Scrum. If that is the case, then I did my part and I’m glad that I’ve made impact in some way. Well then… let’s get Scrumming!

 

— Paul Vincent Nolasco (pnolasco@adobe.com), November 30, 2012.

 

P.S. In all honesty, I’m still quite new practicing Scrum for CQ5 projects. However, regardless of my inexperience I intend to write this document hoping to capture the details I now know and share it to the community as soon as I can. And just like a Scrum project, I intend to “enhance” this document as lessons are learned and more practical details are deemed important to be included.

Scrum in Practice

Posted on November 30, 2012 by Paul Vincent Nolasco | Comments (0)

by Paul Vincent Nolasco

History

Version 0.1 – 11.30.2012 – Chapter 0: Preface and Chapter 1: The Project

 

Table of Contents

0    Preface

1    The Project

2    The Scrum

3    The Team

4    The Toolset

5    The Story

6    The Sprints

7    The Demo

8    The End

 

 NOTE: Any comments or questions to each of the chapters can be posted here.

Becoming a Product Owner

Posted on November 30, 2012 by Paul Vincent Nolasco | Comments (0)

For the past six months I was in project that required for me to become a Product Owner in a Scrum-delivered project. It was a complete change of role that I’m used to. However, I welcomed it whole-heartedly because I find it quite challenging and interesting. The role is brand new within the delivery team and I had to learn it as I go. I enjoyed it immensely,  so much so that I decided to jump ship to this role permanently.

Within the delivery team we are asked to produce quarterly “business development objectives” or BDO that is helpful to the community. Considering the role is quite new within the delivery team, one of the few things that came into my mind for BDO is writing some sort of practical manual for Scrum. There are plenty of manuals, books, entries that explain Scrum in detail (which I’ve read dozens in various forms). But what I found out is the lack of resource that discuss Scrum in practical terms. Something that talks about Scrum in terms of how it was executed in a project. And in terms of using Scrum in WEM/CQ5 projects it’s non-existent.

I know that I’m not an expert on this subject yet. Hence I hesitated whether I should write such a piece. But I’ve learned quite a lot in the past few months, so I’ve decided that instead of forgetting these lessons and important details  it is better to write it down. These entries will not be perfect, there’ll be mistakes. But what I can guarantee is that the content of this guide contains entries that I personally have experienced.

With that said, I introduce to everyone, the guide: “Scrum in Practice”

Over the next few post within my blog I’ll be posting each chapter of this guide. These chapters will serve as my BDOs going forward until its completion. However, just as the practice of Scrum, I plan to update each post as new lessons are learned and new key details are discovered. Eventually, once I’m satisfied with its content I plan to compile them as one document that can be printed or downloaded as needed.

Thanks and I hope you enjoy!

From Design to CQ-fied site

Posted on February 1, 2012 by Paul Vincent Nolasco | Comments (0)

Here’s a scenario for you…

“Your mission should you chose to accept is to build a CQ site in four weeks and all you have is a series of design comps”

Sounds fun eh? Well it actually happens in most projects that I’ve been in. You see in most cases clients decide to build a new site in the following order:

1. Client buys CQ/WEM.

2. Client hires design firm to design the new site.

3. Client hire us to implement the site based on the design comps.

So where/how do you start? (That’s usually the question that clients ask us on the first day of the engagement).

Before I go technical here, there’s ALWAYS one thing that should come first regardless of the project: Business first.

So understand what the project is all about, why CQ/WEM was purchased and what is its driving purpose. Project success are measured not by the elegance of the design nor the complexity of the code, but rather meeting (and exceeding!) the expectations.

Once that is clear then it’s a matter of following few simple rules in the “comps-to-components” translation. (Note, it would be easier to follow the instructions below with samples. Unfortunately most samples that I have are client sensitive data, and it’s hard to find samples online).

1. Identify the templates – Design comps always have some sort of pattern. Even though most designs are quite open-ended and not CMS-optimized (i.e. Most design firms don’t under the concept of re-usability, hence pages are usually designed as pretty as possible without any further thought how it would be translated to code), there is a pattern. Page design usually have a footer and a header and a variation of content in the middle. Whether there’s a left, right or top navigation, there is a pattern.

In most cases, there will always be a “Home Page Template” and a “Default Page Template” (i.e. templates that is used to design internal pages). A Default Page Template can usually be broken down to multiple other templates. It all depend whether you want to create: content templates (templates are used to make it easier/faster for authors to create content without adding any other component), generic templates (templates are open-ended and can add components), or a mix of both. The key here is you want it to be simple and it make sense for authors to use it.

2. Identify the components – This is the most difficult thing in deciding what is a component and what is not based on the comps. It’s easy to take a look and see the structure of the design. There’s a footer there, a header here, a navigation on the side, and so on and so forth. However, the key here is figuring and answering a few things: How will the user insert/edit the content? How will the content be stored? Where does it come from? What is its behavior? As you notice, the theme here is: content. Content is king in the world of CMS. Identifying components should always answer these questions.

However, despite all of these… keep the design simple. Do not complicate the component and make it do too many things at once. You should always think of it as a simple method that does one thing and one thing only. In some cases, you have to make it complex but try to keep it at a minimum.

That’s basically it! Pretty straightforward and simple right? Heh… But as always, practice makes perfect. Enjoy cq-fying those designs!

Additional Notes:

  • Keep in mind that most site designer have no clue how CMS works in general. So if you had to pick, a good component/template design is better than following the design comp.
  • Design comps are just guidelines. At the end of the day  a CQ designer/architect has the final say on how it should look and what make sense in terms of maintaining the code and making it flexible for future changes.
  • Make sure to study the OOTB components/templates that comes with CQ. They’re the best guidelines out there. It’s ships with the product for a reason.
  • Finally… If all else fails you can always blame the designer. :)

 

 

 

No such thing as ADEP WEM Kool-Aid…

Posted on December 3, 2011 by Paul Vincent Nolasco | Comments (1)

“There’s no such thing as an ADEP WEM Kool-aid drinker… only pragmatist”.

What in the world am I talking about?

For the “culturally-challenge” individuals when someone is referred to as “Kool-Aid drinker”  it means someone who blindly believes in a certain ideology without questioning common sense. For the “acronym-challenge” individuals ADEP stands for “Adobe Digital Enterprise Platform” and WEM stands for “Web Experience Management” (Take note that WEM is one of the solution that is provided by the ADEP platform, it used to be referred as Communique but the marketing team doesn’t like the spelling or something).

Pragmatist is someone who make sense, a realist, or pretty much someone who for all purposes believes that in practice lies the true meaning. I’m a pragmatist by heart, and so far it did me well.

So why do I consider those that admire the ADEP WEM platform as pragmatist? Well there are multiple things but to get started I’ll first explain it by listing out the things that I admire about WEM.

  1. One-click wonder – In my previous  consulting engagements where I’m working with other CMS systems, installations can take as long as a week. That’s just installation of the core product. If you want to install the rest of its part then you would have a day or two more. In ADEP WEM, a click or one-execution of command will do the trick. This saves a consultant the hassle of getting everything right and saves the client some consulting budget that could be re-allocate in what actually counts (i.e. building the site).
  2.  It’s all about the package - Compare to other CMS systems almost everything a typical enterprise site would need comes with the core WEM solution. Digital Asset Management is part of the product. A web-based IDE is included or a desktop-based IDE can be downloaded for free. A source-code control system FileVault is included as well. It has it’s own app server with CQSE. It includes basic analytics gathering. Deployment from the “authoring side” to the “publishing side” is part of the product, no need for a separate installation for a FTP like deployment tool.  No database is needed — this saves time and quite a headache since getting any database schema defined by the DB Team of the client usually would need to jump to a series of approvals.  It even comes with an “App Store/Android Market” like capability with Package Share. Oh and that “mobile-revolution” we’re experiencing right now well, it’s there too emulated for your viewing pleasure. In all, with installation alone, it probably saves the client at least two weeks of engagement or if you equate that to the usual consulting rate it results to about $10,000 – 20,000 of savings! (Who doesn’t like saving money?).
  3.  We’re open 24/7 – The core technology is open to the public. JCR, Sling, and OSGI are all open source and can be easily extended using libraries that are available outside the hallowed and secured halls of Adobe.  This results to easy integration with custom systems and environment (which, almost 99.9% sure any engagement would have some sort of custom integration with their system).

In summary… What kind of person wants to build something but want it to be: easy to build, comes with almost everything you need, and “Oh, just in case you’re missing something you can add it in with no restriction”? Yeah… that’s right a pragmatist.

 

 

Hello world wide web!

Posted on October 25, 2011 by Paul Vincent Nolasco | Comments (0)

Welcome to my blog!

A quick introduction. I’ve been working with enterprise content management system from Vignette’s VRD system, Interwoven’s TeamSite, and other open source such as Joomla and Mambo. I’ve started website development around 1999 when I launched my own community of music video editors at: www.nkode.net. Ever since then I’ve enjoyed working in this field and I was lucky enough that my career path lead me to one of the top web innovators of today with Adobe Systems.

I’ve been a technical consultant with two other well-respected software company: HP-Autonomy and OpenText-Vignette and one thing that I learn is that there’s no such thing as a perfect content management system. However, (regardless on how bias this might sound) Adobe’s WEM (formerly known as Communique) is perhaps one of the neatest product that I’ve worked on in building websites. What sets it apart from other product is how robust and well-conceived it is. Heck to start, tell me another CMS that has it’s own web-based IDE? But seriously though, the reason why I think ADEP WEM’s platform is unique than all other CMS I’ve worked before is its repository — CRX. The flexibility of having everything in one location creates a very unique system.

Well, enough of this technical stuff…  I hope you guys/gals enjoy reading my blog. I’ll try to keep it easy to read, more hands-on examples and pictures (in short… NOT BORING… that’s tough for any tech topic). I’ll be posting topics mostly as it relates to Adobe’s Digital Enterprise platform, however I’ll squeeze in some tech topics unrelated to Adobe but related to some CMS or the overall tech industry.

Redundant as it may be… But again I warmly welcome you to my blog!